No and no. I use nonblocking operation when nessesary, not otherwise.
I use RPC-API:s with combined blocking and nonblocking methods, without using threads.
Switching unessesarily between blocking and nonblocking mode on the socket is rather wasteful, as I have previously stated.
The specific use that triggered this discussion, though, is a fully blocking API between child daemons and a master daemon.
I do no, however, want to start read/write threads for each daemon, instead I use a read_callback, blocking writes. Until that check was added if worked perfectly (included the much wanted feature of blocking the main server until the RPC call to the child server succeded)
/ Per Hedbor ()
Previous text:
2003-03-19 13:50: Subject: I/O callbacks in blocking mode
Then you're using threads? Or have you stopped writing network servers?
I mean, the archetypical non-blocking operation is having two sockets connected to two clients, where each client idles a while and then send some request you have to act upon. (And then you have a third fd that you accept on. You could neglect setting that fd into non-blocking mode, and it will probably work most of the time (depending on how select/poll works), but it doesn't seem particularly robust).
In the end, the non-blocking _flag_ is braindamaged. djb is right when he says that operating systems *should* provide nonblocking syscalls read_ndelay and write_ndelay (and accept_ndelay, etc).
/ Niels Möller ()