jmurphy has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

I'm in the process (no pun intended) of writing a forking server. The purpose of the server is to read data from a serial port and write that data to a socket. I'd like to handle several simultaneous clients (all receiving the same data from the serial port). In the future clients will have the option of writing to the serial port via the socket however, that's not in the plan for version 1. BTW Lincoln Stein's book is excellent for anyone interested in network programming using Perl.

My problem is (or will be) access to the serial port (since only one process can access the port at any given time). Therefore I'm in search of design advice. My initial though was to divide the application into two main components:

1) The first component handles serial port I/O: Reading data from the port and writing data to the port.

2) The second component handles socket I/O: Writing data to the socket and reading data from the socket.

Assuming this is a valid design both components will need to talk to each other (pass data back and forth). I'm looking for an elegant solution (or design pattern) that will allow the "serial" component and the "socket" to pass data back and forth. Ideally I rather not have the "serial" component know anything about "clients" that need the data. Rather I'd like the "serial" component to write to some shared memory structure (for example) and then the "socket" component reads from that shared structure and writes the data to the clients.

Does anyone have any helpful design advice? Apologies for the long message.