[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Non-blocking open-network-stream
From: |
Kim F. Storm |
Subject: |
Re: Non-blocking open-network-stream |
Date: |
27 Feb 2002 12:59:04 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 |
Helmut Eller <address@hidden> writes:
> address@hidden (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 <address@hidden> http://www.cua.dk