Closed liamstask closed 8 years ago
I use linux mainly, so this package is better tested there.
I'm not opposed to improving the support on darwin, I've only tested it with Prolific or Arduino faux USB series devices. I'm not sure if O_NONBLOCK is a good idea as the term.Term type implements blocking Read and Write operations, and I suspect O_NONBLOCK will break that contract.
On Mon, Sep 28, 2015 at 3:30 PM, Liam Staskawicz notifications@github.com wrote:
On OS X, only the callout device (/dev/cu.) is supported at the moment, since callin device (/dev/tty) typically requires either:
- hw handshaking
- opening the device with O_NONBLOCK and setting CLOCAL to indicate that hw handshaking should be ignored
CLOCAL is set in setSpeed(), so I was hoping to understand whether this was intentional, or if adding O_NONBLOCK to the open flags would be acceptable?
Otherwise at the moment, syscall.Open() blocks indefinitely when passing in a callin device path.
— Reply to this email directly or view it on GitHub https://github.com/pkg/term/issues/10.
Gotcha, sounds good. Would you be open to a patch that opens with O_NONBLOCK, and follows up with syscall.SetNonblock(fd, false)
before returning from Term.Open()?
resolved by #12
On OS X, only the callout device (
/dev/cu.*
) is supported at the moment, since callin device (/dev/tty*
) typically requires either:O_NONBLOCK
and settingCLOCAL
to indicate that hw handshaking should be ignoredCLOCAL is set in
setSpeed()
, so I was hoping to understand whether this was intentional, or if addingO_NONBLOCK
to the open flags would be acceptable?Otherwise at the moment,
syscall.Open()
blocks indefinitely when passing in a callin device path.