Re: Problems with the url package on w32?

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

Richard Stallman <rms@gnu.org> writes:

>     >     > 1. Make non-blocking connections work on Windows.
>     >     > 2. Make (featurep 'make-network-process '(:nowait t)) return nil on
>     >     >    Windows.
>     >     > 3. Document that make-network-process returns nil if it fails to
>     >     >    create a non-blocking socket.
>     >     > 4. Make make-network-socket do a blocking connect if a non-blocking
>     >     >    connect fails, and document that.
>     >
>     > Why not make it signal an error if it can't do what was requested?
>
>     Hm... that might work.  IMO it should be easy for a program to find
>     out what happened (non-blocking connect doesn't work in this case), so
>     it can perform a certain remedy (doing a blocking connect instead).  A
>     specific error "nowait-not-supported" could be the solution.
>
> Does anyone argue against this?

I just did!

I would like someone to investigate why the non-blocking connect
doesn't work, before deciding what to do.

Does if fail before calling connect (e.g. when setting the socket to
non-blocking), does it fail in the connect itself (what error code is
returned in that case), or does it fail because the emulated select on
w32 doesn't handle non-blocking connect well (it relies on the
write-descriptors).

Maybe a local non-blocking connect (127.0.0.1) succeeds because it
is actually handled as a blocking connect, and returns immediately,
whereas a non-local non-blocking connect fails because the select
system call doesn't work??

If this is the case, windoze doesn't support non-blocking connects,
so (featurep 'make-network-process '(:nowait t)) should return nil.

Perhaps the doc-string for make-network-process should mention using
featurep to check for sub-features.

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