[lcdproc] Blocking calls (we need to change the subject line from time to t ime).

[David Glaude]

Hello all,

I cannot read and follow every discution and message. [too many msg, not
enough time]
Also I will be off-line for a long week (I am affraid my mailbox will
explode with LCDproc mail).
This will give me time to read some more of the discution about keys,
widget, protocol, ...
And maybe write a few lines that will be totally out of date/sync. ;-)

But right now I am asking myself an horrible question and I don't have a way
to test.

>From: Andre Breiler [mailto:andreb@rd.bbc.co.uk]
>On Mon, 26 Mar 2001, William W. Ferrell wrote:
>> --- dglaude@netbrain.be's mailer spewed these beefy chunks ---
>> > Serial communication accross TCP, named pipe, and all special trick or
nice
>> > to have,
>> > can be implemented as an alternate driver.
>
>Yes, but we should have this in mind (blocking call via slow line is not
>the best thing ;)
 
What is CURRENTLY happening if I start LCDd with a MatrixOrbital LCD attach,
and I disconnect the LCD (physicaly).
LCDd is writing to "/dev/serial" whatever the serial is.
But if there is nothing to "read" those caracter on the other side,
are those write calls blocking?
Is LCDd "stuck" trying to write?
Do we CURRENTLY have flow control on the serial line between the LCD and the
"PC"?

If it is "block" or blocking system calls, then OUPS we need to find a
solution,
because this is horible. I don't want one driver/physical screen to block
the whole
LCDd!

But maybe there is no problem currently (but we need keep that in mind if we
start using pipe, named pipe, TCP connection, ...).
In the API between the driver and lcdd we should specify that driver need to
be
non-blocking or such.

David GLAUDE


-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net