Soliciing suggestions for application design

[Oren Tirosh]

On Sat, Mar 22, 2003 at 09:33:37PM +0000, Byron Morgan wrote:
> Greetings all,
> 
> I need to build an app to do the following:
> 
> 1. monitor two serial ports: port A polls for data, B carries responses from
> a population of 1000 mobile radios
> 2. match polls to responses based on timing window (between .033 & .066
> seconds) after poll is transmitted
> 3. do something interesting to selected poll - response pairs
> 4. forward results via inet (as telnet stream or cgi post, not decided yet)
> 
> Should I try to do it all in a single program, using threading (haven't
> tried threading yet), or use a parent app to do the interesting stuff and
> two children to monitor the ports and supply the data? If the latter, how
> best to handle the interprocess comms? I haven't started experimenting with
> the live data yet, but it seems to me the single most important part will be
> to get the timing stuff right (can't be off doing something else while a new
> message is waiting to be read).

The answer doesn't have much to do with Python.

The 33 milliseconds requirement is a little tight for non real-time 
operating systems like Unix and Windows. You will get much better 
resolution most of the time, but it's not guaranteed. How hard is this 
real-time constraint? What is the cost of missing it? A radio system has
a pretty high chance of data loss anyway so I guess it's not too much
of a problem but when it does miss - do you *have* to know that you 
missed so you will not generate erroneous results? Is it ok to timestamp 
the message and do the rest of the processing at a more leisurely pace?

A small C program (or two) running with locked memory and high priority 
could handle the low-level communication and timestamping. It can be 
connected to a Python program that generates and analyses the actual 
messages using popen or a tcp socket.

    Oren