Newsgroups: comp.unix.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!geac!tse!markt
From: markt@tse.uucp (Mark Turner)
Subject: Serial Polling - Opinions?
Message-ID: <1991Jun25.140918.22908@tse.uucp>
Reply-To: markt@tse.UUCP (Mark Turner)
Organization: Toronto Stock Exchange
Date: Tue, 25 Jun 91 14:09:18 GMT


Hi folks. Can anyone out there suggest alternatives to the following 
implementation of a RS-232 serial polling program (explained below)? I'm
mainly interested in the types of solutions that others have found for this
problem. I've listed several areas of concern following the explanation.

Currently, I'm working on a small program that reads a data feed from an 
RS-232 serial port. The application consists of several processes, the first of
which reads data from the port and throws the raw data into a circular buffer 
stored in shared memory (I'll call this the READER process). A second process 
reads the data from the buffer (the PROCESSOR process) and constructs messages 
to send to a SERVER process that is responsible for broadcasting to the 
appropriate clients.

Notes: 

(1) The circular buffer *may* fill, in which case the READER executes the time()
    system call in the hope that the PROCESSOR will be scheduled and free up 
    some room in the buffer. This type of contention has not been a problem 
    to date. 

(2) The PROCESSOR is a simple implementation. It simply uses the open() and 
    read() calls to get at the ASCII transmission.

(3) The priority of these processes have been bumped up so that the READER 
    process has the highest priority of any user processes; hopefully, this will
    prevent data loss when the system is heavily loaded.

Areas of Concern:

(1) This configuration does not guarantee that data won't be lost on the
    incoming line. Yech! Should I be thinking about something like SLIP or
    PPP? (I really don't know much about these protocols.) Should I build much
    of the READER/PROCESSOR functionality into a custom device driver?

(2) Is there any real advantage in splitting the processing between the
    READER and the PROCESSOR? Perhaps they should reside in the same program,
    where the program itself arbitrates between the two operations.

(3) The main design considerations are performance and accuracy. (Is that all?!)

If you've dealt with similar problem, or have a suggestion, I'd appreciate the
help. I'm hoping to avoid some of the common glitches that others have already
dealt with in the past. 

--------------------------------------------------------------------------------
Regards, Mark Turner (markt@tse.UUCP)