emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Asynchronous DNS


From: Eli Zaretskii
Subject: Re: Asynchronous DNS
Date: Tue, 09 Feb 2016 22:48:23 +0200

> From: Alain Schneble <address@hidden>
> Date: Tue, 9 Feb 2016 21:43:10 +0100
> Cc: address@hidden, address@hidden
> 
> - We would get a very robust API that will DT(R)T, regardless of whether
>   an async expert or a non-expert writes code against in.  Both may fall
>   into the blocking "trap".  But those that care will certainly notice
>   it.  They will be the ones that read the documentation carefully,
>   where it will cover this new async subtlety -- that functions
>   accepting an async network process (made with :nowait t) and called
>   before its state turned to "open" may block.
>   
> - It will fix the inconsistency between process-send-* function and the
>   others (such as set-process-coding-system), where the former today may
>   signal errors while the latter do not.  Having process-send-*
>   functions block will certainly only fix issues and shall not introduce
>   new ones.
> 
> - Current (Lisp) API won't change at all.  No need to extend :nowait.
>   Current semantics of nil and t remain.  We do not introduce any new
>   idioms or configurations (e.g. that would be the case with 'immediate)
>   that we might regret in the future.  It should be fully backward
>   compatible.
> 
> - As it does not introduce any new concepts, it leaves the path open for
>   extensions, should it turn out that a strict async programming model
>   might be preferable over "the lax one" described above.  We could
>   still introduce things like this:
> 
>   (make-network-process ... :nowait 'strict-async
>     :sentinel
>     (lambda (p s) (
>       (await p)
>       ...
>      )))
> 
>   ...where await /must/ be called in this 'strict-async mode.  If p is
>   used in a function (e.g. process-send-*) without having awaited it,
>   all these functions would signal an error.  So before any usage, one
>   must await for p.  If p's state is "open", then it's a no-op.  If not,
>   it would block until it is.
> 
> Did I miss something?
> 
> As said, besides the last point, this really is a summary of other's
> (Eli, Lars, Andreas) ideas and remarks.  Thanks you, it's so interesting
> :)

Thanks for a nice summary.  I don't think you missed anything.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]