From: Kalyanov D. <kal...@gm...> - 2010-07-11 08:05:52
Attachments:
handle-listen-fionread.diff
|
Hello! I've found out that it's possible to peek the input buffer size of a Winsock socket by calling WSAIoctl(FIONREAD). I've tried to use it for checking for available input on a socket and it seems to work. Using WSAIoctl works fine when Winsock hadn't been initialized by call to WSAStartup (WSAGetLastError returns WSANOTINITIALISED) and when handle is not a socket (WSAGetLastError returns WSAENOTSOCK). Also this doesn't modify socket in any way while WSAEventSelect sets socket to non-blocking mode and changes its notification event. Are there any problems with this approach? |
From: Nikodemus S. <nik...@ra...> - 2010-09-30 09:23:54
|
On 11 July 2010 11:04, Kalyanov Dmitry <kal...@gm...> wrote: > I've found out that it's possible to peek the input buffer size of a > Winsock socket by calling WSAIoctl(FIONREAD). I've tried to use it > for checking for available input on a socket and it seems to work. > > Using WSAIoctl works fine when Winsock hadn't been initialized by > call to WSAStartup (WSAGetLastError returns WSANOTINITIALISED) and > when handle is not a socket (WSAGetLastError returns WSAENOTSOCK). > Also this doesn't modify socket in any way while WSAEventSelect sets > socket to non-blocking mode and changes its notification event. > > Are there any problems with this approach? I'm don't know nearly enough about Windows to have an educated view on this, but looking at http://msdn.microsoft.com/en-us/library/ms741621%28v=vs.85%29.aspx it seems reasonable enough. If this makes things better for you and others on Windows, I think merging it sounds reasonable enough unless those with more Win-fu have objections. (I didn't review the patch properly yet, though.) I would, however, like a test-case that passes with this but doesn't without. Cheers, -- Nikodemus |
From: Chun T. (binghe) <bin...@gm...> - 2010-09-30 10:28:45
Attachments:
smime.p7s
|
Hi, Nikodemus Siivola I don't think directly merging these code into SBCL core is a good idea. The patch sent from Kalyanov Dmitry was all about sockets, and will cause SBCL always static linking Winsock2 on win32. I cannot figure out why it's relevant to "read-char-no-hang", but since networking code in SBCL are all belong to SB-BSD-SOCKETS contrib package, I think this patch should be put into SB-BSD-SOCKETS, with a slightly modified form. If SBCL core have to add something about networking, that must be a hook to be touched by SB-BSD-SOCKETS when loaded. --binghe 在 2010-9-30,17:23, Nikodemus Siivola 写道: > On 11 July 2010 11:04, Kalyanov Dmitry <kal...@gm...> wrote: > >> I've found out that it's possible to peek the input buffer size of a >> Winsock socket by calling WSAIoctl(FIONREAD). I've tried to use it >> for checking for available input on a socket and it seems to work. >> >> Using WSAIoctl works fine when Winsock hadn't been initialized by >> call to WSAStartup (WSAGetLastError returns WSANOTINITIALISED) and >> when handle is not a socket (WSAGetLastError returns WSAENOTSOCK). >> Also this doesn't modify socket in any way while WSAEventSelect sets >> socket to non-blocking mode and changes its notification event. >> >> Are there any problems with this approach? > > I'm don't know nearly enough about Windows to have an educated view on > this, but looking at > http://msdn.microsoft.com/en-us/library/ms741621%28v=vs.85%29.aspx it > seems reasonable enough. > > If this makes things better for you and others on Windows, I think > merging it sounds reasonable enough unless those with more Win-fu have > objections. (I didn't review the patch properly yet, though.) > > I would, however, like a test-case that passes with this but doesn't without. > > Cheers, > > -- Nikodemus > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Kalyanov D. <kal...@gm...> - 2010-10-01 18:26:24
Attachments:
test-win32-socket-r-c-n-h.sh
|
On Thu, 2010-09-30 at 12:23 +0300, Nikodemus Siivola wrote: > On 11 July 2010 11:04, Kalyanov Dmitry <kal...@gm...> wrote: > > > I've found out that it's possible to peek the input buffer size of a > > Winsock socket by calling WSAIoctl(FIONREAD). I've tried to use it > > for checking for available input on a socket and it seems to work. > > > > Using WSAIoctl works fine when Winsock hadn't been initialized by > > call to WSAStartup (WSAGetLastError returns WSANOTINITIALISED) and > > when handle is not a socket (WSAGetLastError returns WSAENOTSOCK). > > Also this doesn't modify socket in any way while WSAEventSelect sets > > socket to non-blocking mode and changes its notification event. > > > > Are there any problems with this approach? > > I'm don't know nearly enough about Windows to have an educated view on > this, but looking at > http://msdn.microsoft.com/en-us/library/ms741621%28v=vs.85%29.aspx it > seems reasonable enough. > > If this makes things better for you and others on Windows, I think > merging it sounds reasonable enough unless those with more Win-fu have > objections. (I didn't review the patch properly yet, though.) > > I would, however, like a test-case that passes with this but doesn't without. The test case can be found at http://article.gmane.org/gmane.lisp.slime.devel/7991 and I'm attaching a modified version of it that can be run from shell. Unfortunarely I don't know how to convert it to pure lisp code. This test tries to read from a connected socket when no data is available and read-char-no-hang should return NIL while instead it blocks until first byte is available. |