I don't have a really strong opinion on that, but I think it makes sense to make it difficult to get into that mode of operation by mistake.
I expect the backend not to block, ever, so it is fair if the backend (or some other part of the callback machinery) complains if I'm using it in such a way that it no longer can guarantee that.
I have no problem if there's a documented way to say "do what I say, I'll take the responsibility of designing my protocols and clients in such a way that they won't deadlock", but it's not something I'll recommend in general, as it puts part of the responsibility for server security (that the server shouldn't hang) onto the clients.
Where possible, the pike interface should hide the difficulties and subtle problems of the operating system services.
/ Niels Möller ()
Previous text:
2003-03-19 14:03: Subject: I/O callbacks in blocking mode
And you would also like to enforce that in pike, even if it breaks quite a few valid uses?
We never did that kind of things before. Actually, we specially added the set_read_callback with friends functions to _allow_ this kind of things.
If we do not allow read-callbacks with blocking sockets, we might as well remove the methods to set them, since they are bound to cause "problems" (like my quite intentional use of blocking sockets with asynchronous notification when data is available, to avoid read threads).
/ Per Hedbor ()