[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.
- Re: Asynchronous DNS, (continued)
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/07
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/07
- Re: Asynchronous DNS, Alain Schneble, 2016/02/08
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/08
- Re: Asynchronous DNS, Alain Schneble, 2016/02/08
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/08
- Re: Asynchronous DNS, Alain Schneble, 2016/02/09
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/09
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/09
- Re: Asynchronous DNS, Alain Schneble, 2016/02/09
- Re: Asynchronous DNS,
Eli Zaretskii <=
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/09
- Re: Asynchronous DNS, Alain Schneble, 2016/02/10
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/11
- Re: Asynchronous DNS, Alain Schneble, 2016/02/12
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/12
- Re: Asynchronous DNS, Alain Schneble, 2016/02/13
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/13
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/14
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/14
- Re: Asynchronous DNS, Stefan Monnier, 2016/02/14