Well, one use is to have an application that reads from stdin without a read-thread. That is not possible now unless you want to block.
Another use is the one I described:
+---------------+ | Main server | +---------------+ | | +----+ +----+ | dl | | ul | +----+ +----+
This code has been very much simplified to make it readable:
In the main server:
class Daemon { Stdio.File fd; mixed do_command( string name, mixed args ) { int len; fd->write( encode_command( name, args ) ); sscanf( fd->read( 4 ), "%4c", len ); return decode_value( fd->read( len ) ); } }
In the daemons:
void got_command( ) { int len; sscanf( fd->read( 4 ), "%4c", len ); mixed res = do_command( decode_command( fd->read( len ) ) ); res = encode_value( res ); fd->write( sprintf("%4c%s", strlen(res), res ) ); }
int main() { fd = Stdio.File( 4, "rw" ); fd->set_read_callback( got_command ); // .. go on to set up other things, like a port to listen to, taskt // to do etc .. return -1; }
/ Per Hedbor ()
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 ()