Re: [Chicken-users] udp egg on win32

[Daishi Kato]

Hi Hans,

At Sat, 4 Feb 2006 15:38:48 +0100,
Hans Bulfone wrote:
> > Recently, I'm working on win32, and found one thing.
> > (udp-recvfrom) blocks when it's run in a thread.
> > Of cource, with a non-blocking socket.
> 
> i don't know very much about windows networking stuff, but i hope
> my thoughts might be helpful anyway.
> 
> i may be wrong, but imho the distinction between blocking
> and non-blocking sockets in udp-open-socket/udp-open-socket*
> is not very useful with chicken, because you always need
> non-blocking sockets if you don't want the recv()-calls
> to block all threads. (or you select() before every
> recv() call)
> 
> the udp-recv... procedures always block the current thread
> because of the restart-nonblocking loop.

Yes, I know this. Basically, I first code on linux,
and port it to win32. It works fine on linux.

> > Looking into tcp.scm, I noticed that 
> > some (##sys#thread-block-for-i/o) are commentted out.
> > So the same thing is done in udp.scm,
> > and it worked.
> 
> you mean the (udp-recvfrom) does not block the current thread
> then? or does not block all threads?

All threads, I meant.

> imho, they should not be commented out, because they are
> needed to tell the scheduler that the thread is waiting
> for some socket to be ready for reading or writing.
> 
> the scheduler then only invokes the thread when the
> socket is ready.

So, is it like a select() call?

> without the ##sys#thread-block-for-i/o call, the scheduler
> invokes the thread repeatedly, the thread calls recv(),
> gets EWOULDBLOCK and (yield)s again.  this wastes a lot of
> cpu time, especially when all threads are waiting for i/o.

Ah, you are right. This is why it worked on win32.
I guess ##sys#thread-block-for-i/o does not work correctly
on win32, and without it, the thread is invoked repeatedly,
letting the program work WITH lots of cpu time...

Would there be a piece of code to see if
##sys#thread-block-for-i/o is really working?

> but ihmo, (udp-recvfrom) would still block the current thread,
> calling recv() in a loop, when you remove the
> ##sys#thread-block-for-i/o.

Yeah, but I was talking about the entire process (all threads).
Sorry about my unclear explanation.

Daishi