Re: Non-blocking open-network-stream

[storm@cua.dk (Kim F. Storm)]

Helmut Eller <helmut@xaital.km4u.net> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > Here is my second attempt at a patch to support non-blocking
> > open-network-stream.
> 
> I think the problem I described last time is still present.  The
> problem is that the filter is invoked before the sentinel.  This
> happens when the stream is readable immediately after the transition
> from connect state to open state.

I've made the chage you suggested.  Thanks.

There is a general problem with handling a request for non-blocking connect
on systems which does not support this.

As I have specified this now, open-network-stream will proceed to
emulate a non-blocking connect -- which means that it will block.  And
when the connect completes, it continues to pretend that the connect
was non-blocking, so it setup the sentinel to be called after return,
and all that jazz.

I think it would be much cleaner if (open-network-stream ... t) simply
returns nil if it doesn't support non-blocking connect.

Then the code can do some smarter things (like delaying the connect),
and I don't have to mess up the C code with all sorts of hacks to delay
the delivery of a "failed to connect" message on a process which would
not otherwise have to exist.

Does this sound acceptable (since there is currently no code supporting
non-blocking connect, this cannot break anything :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel