chicken-hackers
[Top][All Lists]
Advanced

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

[Chicken-hackers] [PATCH] Fix nonblocking socket behaviour on Windows


From: Peter Bex
Subject: [Chicken-hackers] [PATCH] Fix nonblocking socket behaviour on Windows
Date: Wed, 20 Nov 2013 23:20:57 +0100
User-agent: Mutt/1.4.2.3i

Hi all,

Due to Shanmuhanathan's report I looked into Spiffy on Windows, and found
out that multithreaded socket handling is completely broken there.
Sockets are marked as nonblocking in tcp.scm, but that's done through
fcntl() which is #defined as a no-op on Windows (because Windows has no
fcntl() at all), so this could never have worked in the first place.

I found some notes in the Windows documentation about some select()-like
procedure automatically marking any sockets you pass to it as nonblocking,
so perhaps this may have obscured this problem in the past if somehow
a thread yielded before reading from such a socket.

Attached is a patch which enables the marking of sockets as nonblocking
for Windows.  This should definitely go into the stability branch!

So far I haven't been able to write a simple test for this, but simply
running Spiffy, requesting a page AND THEN REFRESHING THE PAGE will
easily trigger a hang (due to it waiting for more input), on any
HTTP/1.1 browser which implements keepalive and does not send too many
headers.  This seems to happen only on MingW, on MingW-msys it hangs
for me even on the first request.

The actual value of the pointer argument to ioctlsocket() seems to be
ignored except for that it must be not NULL, so for convenience I just
passed the fd pointer.  It is declared as a u_long *, but relying on
that detail seems a little brittle to me, so I'm casting it to (void *)
in order to shut the compiler up.  Really, you have to be wondering what
these people at Microsoft were thinking when they implemented this mess.

Cheers,
Peter
-- 
http://www.more-magic.net

Attachment: 0001-Fix-nonblocking-socket-behaviour-on-Windows-by-actua.patch
Description: Text document


reply via email to

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