I've run into a problem where the open function never returns when I try to open a serial port. It doesn't happen all the time, and the problem disappears for a while if I unplug my USB to serial adapter and plug it back in. My code looks like this:
fileDescriptor = open(bsdPath, O_RDWR | O_NOCTTY);
where bsdPath is /dev/cu.KeySerial1 . I've tried adding the O_NONBLOCK option to the open command, but it still hangs.
Of course I'd like to understand why this is happening. My belief is that whatever the problem, with O_NONBLOCK specified, open should return no matter what even if it was unable to open the port. If it's unable to open the port, fileDescriptor should be -1 and errno should be set (I check for this immediately after the call to open). Of course, this isn't happening. Is my assumption incorrect? Is there some known reason for open() to never return even with O_NONBLOCK specified when an error is encountered?
Using the latest version of the Prolific PL-2303 driver with a PL-2303 based USB to serial adapter on 10.7.2, I've been able to reproduce this problem again today. A few notes:
- When hung in the
open()
call, the process is not interruptible using command-. (control-C). - Running
ps -avx
shows a process state code of U for the process. I'm not sure what this code means. It doesn't appear in man pages forps
found by Googling. There is no listing of process state codes in the man page forps
on my machine. Perhaps it's specific to the Mac (10.4+?) version ofps
? - I noted that on the run immediately before the first appearance of this problem, my call to
ioctl()
to reset the options on the port back to their state before I changed them for use in my program hung. I had to kill the program (via Xcode's debugger). Immediately after this, on the next launch of the program,open()
hung...