On Saturday 15 August 2009 04:03:42 Terry Reedy wrote: > greg wrote: > > You can't read and write with the same stdio file object > > at the same time. Odd things tend to happen if you try. > > I believe the C standard specifies that the behavior of mixed reads and > writes is undefined without intervening seek and/or flush, even if the > seek is ignored (as it is on some Unix systems). With two threads, the > timing is undetermined.
For a serial port, flush on write makes some sense, but seek is complete nonsense because it is undefined, and besides- the point you try to seek to may never come around. So the message I am getting loud and clear is that the basic thing I am doing wrong is to use the ordinary python open() instead of os.open(). As for the timing in two threads - Yes you are right, but there is not a lot one can do about it - The right solution depends to a large extent on what you are doing - for instance, if you are writing a polling protocol (such as Burroughs poll-select, or Uniscope), then you want a loop that transmits something, and waits for an answer or time out. This is essentially half duplex, and in a high level language the natural structure to write this is in one thread. On the other hand, if you are writing a sliding window type protocol that is capable of pouring stuff into a link asynchronously from both ends, then the natural way to do it is to use two threads - one to handle incoming stuff, and the other to squirt out the data that must go out. If, as is true in my case, the source of outgoing data and the sink for incoming data is a TCP/IP socket, then one can accomplish this with blocking I/O quite efficiently, provided you have a third thread looking after overall timing Issues. For such a case, the timing is essentially determined by the flow of the data (provided of course that you can keep up with the link speed). When one introduces another variable into the equation, namely the requirement to do a transmission at least every n milliseconds, (a feel-good keepalive) then you need a time out on the sources, so that you can either do a transmission or raise an alarm because a reporting period was missed. So then you are back at a loop waiting for input or timeout, and doing a transmission afterwards. Only now there are two of them, facing in opposite directions. I think this sort of thing is better written at a lower level where one has access to the interrupts from the ports, as well as a timer interrupt to handle timing and timeout issues. But that is a lot of work, so I make do with python. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
