This is an offshoot of the thread "Having trouble porting an application to MS-Windows". This time I am looking at using fork() to separate input and output handling. But I am not sure how some of the IPC handling works in the Win32 environment.
I am trying to emulate the behavior of an existing POS system currently installed at a client location without having to install and set up a copy of that system. I want to create two threads, one to read data from a serial port and one to write data to that same serial port. The data in both cases is a framed packet with checksum and ACK/NAK responses. This will have the affect of enabling full-duplex operations on the serial port, where my previous version was, in effect, two-way alternating half duplex. The framing is done with ASCII characters, like so: <SOH>header<STX>content<ETX>checksum<EOT> 1. The read thread must input the packet, validate the checksum and send ACK/NAK out the port, via the write thread. The content is then stored or sent on. It must also forward any ACK or NAK received to the transmit thread. There is no chance of an ACK or NAK embedded in the packet, so escapes are not necessary. 2. The write thread must frame the packet, insert the checksum, and transmit it. Then it must wait up to three seconds for an ACK or NAK. If it receives the ACK, it waits for another message. If it gets a NAK, or times out, it transmits the packet again, up to three times. After three tries, an error is recorded and it looks for another message. It also must insert the ACK/NAK from the receive thread into the transmit data stream, although that can be held until after the current packet has been sent. I have two questions about this. First, is there a standard Perl IPC interface between threads? I am not familiar with pipes in this context, although I have used mailboxes and single word messages in various multi-processing environments, including POSIX threads. Second, is there a way to set this up so the transmit thread timeout can be easily implemented as a side effect of waiting for the ACK/NAK to arrive on that interface? I was thinking of using a semaphore, but they don't appear to be implemented on Win32. For this emulation, the outgoing messages are read from a text file and the incoming messages are stored in another text file. Timing of outgoing messages is controlled when that file is read. I am hoping this can provide a workaround for the alarm failure I ran into on the single threaded version as well as being a better emulation of the actual system. Thank you, Bob McConnell Principal Communications Programmer The CBORD Group, Inc. 61 Brown Road Ithaca NY, 14850 Phone 607 257-2410 FAX 607 257-1902 Email [EMAIL PROTECTED] Web www.cbord.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
