emacs-devel
[Top][All Lists]
Advanced

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

Re: Asynchronous DNS


From: Lars Ingebrigtsen
Subject: Re: Asynchronous DNS
Date: Mon, 08 Feb 2016 13:03:44 +1100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

> Please consider the plight of a programmer who needs to implement such
> a connection.  It would be much more complex and hard to get right
> than what we have today.  E.g., look at smtpmail.el: it opens the
> network stream, sets up the process filter and encoding, and
> immediately proceeds to sending the HELO command to the server.
> Imagine how much more complex this simple job would be if it needed to
> jump through hoops as you described above.

Ideally, when you're sending mail with smtpmail.el, it would all happen
without Emacs being blocked, right?  So that the user can go on reading
the next email.

But that can't be done without doing major changes to smtpmail.el.  Way
errors are propagated back to the callers would have to change, for
instance.

I guess what I'm saying is this: If you're fine blocking Emacs, then you
don't use :nowait 'immediate.  Then everything happens one step at a
time (DNS, connect, TLS, EHLO, QUIT).

If you wish to make things happen "in the background", then you will
have to change your application in major ways.  Making one of those
things the rule "you have to wait until the process changes state to
"connected" is an insignificant part of that rewrite.

> They all should call a single function that waits calling gai_error
> until the connection completes, and signals an error if it completes
> with a failure indication.

Then you're back to making a blocking connection, which is something
that somebody who's said :nowait 'immediate would not want.  So I don't
really see the point here.  It's better to just have those functions
signal an error, I think, which is what they currently do...

> Yes, I understand.  But I don't think this is a proper way to be
> backward compatible.  With my suggestion, code remains backward
> compatible even if it uses :nowait.  This is better, IMO, because it
> leaves more applications backward compatible.  For example, imagine
> that :nowait comes from some higher level, so the level that arranges
> the connection has no idea whether it needs to do the simple thing or
> the complex one.  What Lars suggested means that every application
> that doesn't pass literal parameters to make-network-process will now
> have to analyze the parameters passed by the caller, to see if :nowait
> is there and what is its value.  I don't expect package maintainers to
> love this.

Hm...  I don't understand.  An application that wants 'immediate will
just say ":nowait 'immediate".  The only thing that examines the :nowait
parameter (to distinguish 'immediate, nil and non-nil) is
make-network-process.

Unless I'm missing something.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



reply via email to

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