On 23/09/2008 11:21 AM, James Teh wrote: > 1. Initialise brlapi. > 2. Write some text to the display, just to ensure all is working. > 3. Press a key on the display. > 4. Write some more text to the display without first calling > readKey(False). This call will block. Further investigation reveals that the brlapi server (i.e. brltty itself) blocks in step 3; i.e. when the key is pressed. I can determine this because I cannot stop the brlapi service; brltty never responds to the service termination request.
I suspect it is blocking when it tries to write the key to the client. I don't quite understand the code yet, but am I right in assuming that it relies on the behaviour of Unix sockets whereby a certain amount of data can be written (buffered) without the write operation blocking? I am not certain, but perhaps this is different with local named pipes in Windows; i.e. perhaps they block on the write operation waiting for the remote end to read the data. MSDN mentions a FILE_FLAG_WRITE_THROUGH mode for network named pipes which causes this behaviour, but it says it doesn't apply to local named pipes. It is unclear as to whether it is just always enabled for local named pipes (no buffering), which I suspect is the case. Jamie -- James Teh Email: [EMAIL PROTECTED] WWW: http://www.jantrid.net/ MSN Messenger: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] Yahoo: jcs_teh _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://mielke.cc/mailman/listinfo/brltty
