You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am wondering if a SerialPort 'signals' event was ever considered - to complement getSignals. To detect changes on RI, DCD and DSR (and CTS), the application needs to continually poll by invoking getSignals. I guess one can just poll with getSignals() every 100-500ms or so, but it seems to diverge from good asynchronous programming.
Was a SerialPort 'signals' or 'signalschange' event overlooked, or intentionally omitted for simplicity?
From a latency perspective, polling getSignals() every 100–500 ms imposes an artificial detection floor even on platforms that can report changes immediately.
It may be useful to specify signalschange as best-effort/event-driven: platforms with native notification use it directly; implementations without it may internally poll.
That keeps the cross-platform API consistent without requiring every OS backend to expose the same primitive.
Activity
reillyeon commentedon Mar 19, 2024
I considered it but if I recall correctly Windows provides an API to listen for changes to these signals but POSIX (Linux and macOS) does not.
sn4kebite commentedon May 2, 2024
On Linux at least there's the
TIOCMIWAIToperation forioctlthat accomplishes this.reillyeon commentedon May 2, 2024
If you spawn a thread exclusively for the purpose of waiting for signals. POSIX has frustratingly poor support for asynchronous I/O.
kvnloo commentedon Oct 1, 2026
From a latency perspective, polling
getSignals()every 100–500 ms imposes an artificial detection floor even on platforms that can report changes immediately.It may be useful to specify
signalschangeas best-effort/event-driven: platforms with native notification use it directly; implementations without it may internally poll.That keeps the cross-platform API consistent without requiring every OS backend to expose the same primitive.