Temporary workaround: (use posix) and then, after creating the socket, do either:
(##sys#file-nonblocking! (socket-fileno *socket*))
or equivalently
(file-control fcntl/setfl (socket-fileno *socket*)
(bitwise-ior (file-control fcntl/getfl (socket-fileno *socket*))
open/nonblock))
Neither workaround will work on Windows.
Permanent fix: We should probably make all sockets nonblocking at creation time instead, since our machinery assumes nonblocking sockets. We could expose the set-nonblocking operation to the user, but since TCP is always nonblocking, doing this only for UDP would be strange. Thoughts?
Jim
On Jun 14, 2013, at 11:01 AM, Kristian Lein-Mathisen <
address@hidden> wrote:
I have come across a problem with multiple srfi-18 threads when tryping to listen to UDP sockets:
(use socket)
(set! *socket* (socket af/inet sock/dgram ))
(set! (so-reuse-address? *socket*) #t)
(socket-bind *socket* (inet-address "0.0.0.0" 5055))
;; (socket-receive ..) here blocks the prints below
;; after 1 s (about 10 hello's)
(thread-start! (lambda ()
(thread-sleep! 1)
(print "receiving ...")
(print (socket-receive *socket* 1024))
(print "done")))
(let loop ()
(print "hello from main-thread!")
(thread-sleep! .1)
(loop))
;; the hello's from the main thread continue after sending a udp packet:
;; $ echo test `date` | socat - UDP-DATAGRAM:127.0.0.1:5055,broadcast
The documentation for socket clearly states that socket-receive should not block:
This call will block until data is available, but other threads can proceed.
What is wrong with my socket fd?
K.
Chicken-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/chicken-users