voodootikigod/node-serialport — pull request #40 by prwhite (2012-02-27 05:57:55+00:00)
Title: Forward "open" event from ReadStream for completeness.

I'm currently working on an Arduino project where I would like to be able to reliably open and close the serial port, potentially any number of times.

I thought it would be nice to have the _open_ event from the _fs.ReadStream_ emit to the serialport consumers, so I've added that based on the other events forwarded from the underlying _ReadStream_.

On a related note, while I am now getting the _open_ event reliably, I have yet to get the _close_ event from the serial port module. Doing an _open, close, open_ scenario, after the second _open_, the serial port on the Arduino is not reset and no data is available to read. I've dug into the serial port module and node itself but haven't yet resolved what the issue is. I'll keep plugging at this... but if you know any specific reason why this might not be working, that could be helpful.

I have run dtruss/strace on my test script and it appears that the serial port module actually opens and closes the serial port correctly, but the _ReadStream_ in node is actually not closing when _destroy_ is called. This looks to be the stream of system events from the _node_ I/O threads:

```
38512/0x229474: 8 thread_selfid(0x7FFF7A68DFB8, 0x0, 0xFFFFFFFF)	= 2266228 0
38512/0x229474: 33 open("/dev/tty.usbserial-11IP1559\0", 0x0, 0x1B6)	= 7 0
38512/0x229474: 40 write(0x5, "\0", 0x1)	= 1 0
38512/0x229474: 52 psynch_cvwait(0x106DE8700, 0x100000100, 0x0)	= 0 0
38512/0x229474: 68 read(0x7, "\0", 0xFF)	= 10 0
38512/0x229474: 84 write(0x5, "\0", 0x1)	= 1 0
38512/0x229474: 101 psynch_cvwait(0x106DE8700, 0x10100000200, 0x100)	= 0 0
38512/0x22949c: 12 thread_selfid(0x7FFF7A68DFB8, 0x0, 0xFFFFFFFF)	= 2266268 0
38512/0x2294f7: 14 thread_selfid(0x7FFF7A68DFB8, 0x0, 0xFFFFFFFF)	= 2266359 0
38512/0x2294f7: 34 open("/dev/tty.usbserial-11IP1559\0", 0x0, 0x1B6)	= 8 0
38512/0x2294f7: 38 write(0x5, "\0", 0x1)	= 1 0
38512/0x2294f7: 44 psynch_cvwait(0x106DE8700, 0x20100000300, 0x200)	= 0 0
```
To me, the most interesting thing above is that there is no _close_ call and that the second _open_ allocates a higher fd value, which doesn't happen in the _serialport_ module, which did have the same fd allocated that was closed earlier in the process. Thus it's like the fd for the first _ReadStream_ is still open.

As a point of comparison, I have written a straight C++ test that can successfully open, close and re-open a serial port here: https://gist.github.com/3558773c22ad80c5028d. So, it doesn't seem to be a device or driver issue. The node code that I'm testing with is here: https://gist.github.com/fc4d3d7d664f348d05a9.