On 2009-08-14, Hendrik van Rooyen <hend...@microcorp.co.za> wrote:
> In the past, on this group, I have made statements that said
> that on Linux, the serial port handling somehow does not allow
> transmitting and receiving at the same time,
That's not true. Linux/Unix does and always has supported
full-duplex communications on serial ports.
> and nobody contradicted me.
Um, sorry, I guess.
> What I would really like is to have two threads - one that
> does blocking input waiting for a character, and one that
> examines an output queue and transmits the stuff it finds.
That's the traditional way of doing full-duplex serial IO on
Unix back in the day before the select/poll system calls were
available.
> When I try to do this, it does not seem to work - as far as I
> can see, it is as if the underlying implementation is somehow
> single threaded - if it is waiting for a received character,
> it waits until something comes in before it will transmit
> anything.
Nope. I'll try to dig up an example, but that approach has
always worked for me.
> So if you are talking to a device that does not respond, the
> whole thing freezes up waiting for a character that never
> comes, and nothing is transmitted either, despite the call to
> port.write(somestring). The write blocks, and everything
> stops, waiting for the receipt to finish.
I've never observed that behavior.
> Is there a way to get full duplex, so that the transmit and
> receive are independent of each other?
That's the way serial ports work on Unix.
> Or are we stuck with a disk-like model that forces a sequence
> on reads and writes?
No.
--
Grant Edwards grante Yow! Like I always say
at -- nothing can beat
visi.com the BRATWURST here in
DUSSELDORF!!
--
http://mail.python.org/mailman/listinfo/python-list
