hi, On Fri, Feb 03, 2006 at 05:45:18PM +0900, Daishi Kato wrote: > Hi, > > 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. > 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? 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. 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. 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. regards, hans. _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
