Serial ports have basically three error conditions:

1. Serial adapter (USB dongle) unplugged.
2. Serial cable unplugged
3. Remote device hanging/not reacting

(1) is something that needs to be handled in the driver and the Win32::SerialPort module. I don't use Windows (and my coworker uses hardware that has an integrated USB port), so i'm not sure exactly how to detect and handle this.

Depending on the circumstances, you may or may not be able to detect (2). With modern USB Dongles and devices not using most of the serial lines, there might be no way to detect (by hardware) if the cable is plugged in, so you'd handle (2) like (3), see below. If it is a a classic serial connection with all the signals, you might be able to inquire the status of "Data terminal ready" and "Data Carrier detect" (i think) lines, but i rather doubt that your setup still has support for these.

For (3) and most likely (2), the only thing you can do is exchange some sort of keep-alive messages. Many serial protocols have a way of doing that, but this really is device specific. Maybe the protocol has some sort of lifeticks you can request from the remote device. Or you can try to request some sort of device status if you have not received data from that device in a certain timeframe. Some protocols also have dummy/no-operation commands. If the device has a way to identify itself (often implemented on replies to ENQ or DC* bytes, see your favourite ASCII table), you can also use that to check if the device is still working.

Hi cavac,

thanks for your reply. My problem is the first one you list. This leads to a hangup, when any write or input actions are tried.

But I found out by accident, that the is_status method of the underlying Win32API::CommPort package provides a non-blocking means to find out, if the serial adapter is still connected. The function returns a list of 4 values if all is OK - usually all 0 - or undef, if the adapter was disconnected.

Luckily is_status is also very light-weight, so I can just call it anytime I try to send something over the port. Of course, there's still a slight chance, that the disconnection happens just between the call to is_status and the call to write or input something via the port, but I can live with that (low) risk.

You might be able to fork() the process at startup, where the parent does all the logic and stuff, and the child only does the low level serial communication. Then the parent can periodically check if the child still reacts, and restart it if required.

I'm not what the best way to do IPC between the processes on Windows, i am a Linux guy. From what i understand, Unix domain sockets (AF_UNIX) are now available when using at least Win10 and a modern version of Perl, otherwise you can just use TCP on localhost.

I wrote a forked program example (for Linux) in Autoclicker! Cheating is winning, too! (look for the header "VERSION 2") that does inter-process communication. Maybe this is some help to your problem.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
Also check out my sisters artwork and my rather simple sketches/one-panel comics

Using (POSIX) signals on Windows is not really supported. Just like fork(), they work surprisingly well, but the point is that they are implemented at all, not how good they are implemented.