receiving data delayed / loop issues

[Holger-Will]

prelude

i have a problem which is a bit hard to explain. but i'll try:

i have a simple express+socket.io server which acts as a serialport to websocket gateway.
it is part of a lib i'm developing: https://github.com/enocean-js/enocean-js

the server code can be found here: https://github.com/enocean-js/enocean-js/blob/master/packages/node_modules/%40enocean-js/websocket-gateway/server.js

if you clone the repo, and npm i, everything works as expected...
but when i remove my package.lock and then npm i the Bug show up.

i'm using my own parser: https://github.com/enocean-js/enocean-js/blob/master/packages/node_modules/%40enocean-js/serialport-parser/src/serialport-parser.js

Bug

when receiving data on the serialport, the parser.on("data",...) event does not fire when the parser finished parsing the input, but after a few seconds, all detected packets/events are emitted.

in the meantime i can still write to the port without a problem.

now here comes the part i hope will help you find the problem: when i insert a timer

setInterval(()=>{},0)

everthing works again as expected... moreover, if i set the interval to any value, the events are fired at exactly that interval...

i hope this gives you a hint at where the problem might be...

p.s.

i'm on linux (Arch)
tried with different node versions (my min-version is 8.4.0) up to 11.4.0.

[mhmtsrfglu]

setInterval(()=>{},0)
It solved my problem. Thanks for solution

[reconbot]

Can you run npm ls before and after removing your package-lock.json? I would like to know if the serialport version changes

[Holger-Will]

before:
serialport@7.1.0
after:
serialport@7.1.1

[reconbot]

Can you test a simple setup, maybe a console log, with the two versions?

…

On Sat, Dec 22, 2018, 2:57 PM Holger Will ***@***.***> wrote: after: ├─┬ ***@***.*** │ ├─┬ @***@***.*** │ │ ├─┬ @***@***.*** │ │ │ └─┬ ***@***.*** │ │ │ └── ***@***.*** │ │ └─┬ ***@***.*** │ │ └── ***@***.*** │ ├─┬ @***@***.*** │ │ ├── @***@***.*** deduped │ │ ├── @***@***.*** deduped │ │ ├── ***@***.*** │ │ ├─┬ ***@***.*** │ │ │ └── ***@***.*** │ │ ├── ***@***.*** │ │ └─┬ ***@***.*** │ │ ├── ***@***.*** │ │ ├── ***@***.*** │ │ ├── ***@***.*** │ │ ├── ***@***.*** │ │ ├── ***@***.*** deduped │ │ ├── ***@***.*** │ │ ├─┬ ***@***.*** │ │ │ └── ***@***.*** deduped │ │ ├── ***@***.*** │ │ ├─┬ ***@***.*** │ │ │ ├─┬ ***@***.*** │ │ │ │ ├── ***@***.*** │ │ │ │ └─┬ ***@***.*** │ │ │ │ ├── ***@***.*** │ │ │ │ ├── ***@***.*** deduped │ │ │ │ ├── ***@***.*** deduped │ │ │ │ ├── ***@***.*** │ │ │ │ ├── ***@***.*** deduped │ │ │ │ ├─┬ ***@***.*** │ │ │ │ │ └── ***@***.*** deduped │ │ │ │ └── ***@***.*** │ │ │ ├── ***@***.*** │ │ │ ├─┬ ***@***.*** │ │ │ │ ├── ***@***.*** │ │ │ │ ├── ***@***.*** deduped │ │ │ │ ├── ***@***.*** │ │ │ │ ├── ***@***.*** deduped │ │ │ │ ├── ***@***.*** │ │ │ │ ├─┬ ***@***.*** │ │ │ │ │ ├── ***@***.*** │ │ │ │ │ ├─┬ ***@***.*** │ │ │ │ │ │ └── ***@***.*** │ │ │ │ │ └── ***@***.*** deduped │ │ │ │ ├── ***@***.*** deduped │ │ │ │ └─┬ ***@***.*** │ │ │ │ └── ***@***.*** deduped │ │ │ └── ***@***.*** │ │ ├── ***@***.*** │ │ ├─┬ ***@***.*** │ │ │ ├─┬ ***@***.*** │ │ │ │ └── ***@***.*** deduped │ │ │ └── ***@***.*** deduped │ │ ├─┬ ***@***.*** │ │ │ ├── ***@***.*** │ │ │ ├── ***@***.*** │ │ │ ├── ***@***.*** │ │ │ └── ***@***.*** deduped │ │ ├─┬ ***@***.*** │ │ │ ├─┬ ***@***.*** │ │ │ │ └── ***@***.*** │ │ │ ├── ***@***.*** deduped │ │ │ └── ***@***.*** │ │ ├─┬ ***@***.*** │ │ │ ├── ***@***.*** │ │ │ ├── ***@***.*** deduped │ │ │ ├─┬ ***@***.*** │ │ │ │ ├── ***@***.*** deduped │ │ │ │ └── ***@***.*** deduped │ │ │ └─┬ ***@***.*** │ │ │ ├─┬ ***@***.*** │ │ │ │ ├── ***@***.*** deduped │ │ │ │ └── ***@***.*** deduped │ │ │ ├─┬ ***@***.*** │ │ │ │ ├── ***@***.*** │ │ │ │ └── ***@***.*** │ │ │ ├── ***@***.*** deduped │ │ │ ├── ***@***.*** │ │ │ ├── ***@***.*** deduped │ │ │ ├── ***@***.*** │ │ │ └── ***@***.*** deduped │ │ ├─┬ ***@***.*** │ │ │ └── ***@***.*** deduped │ │ └── ***@***.*** │ ├── @***@***.*** │ ├── @***@***.*** │ ├── @***@***.*** │ ├─┬ @***@***.*** │ │ └── @***@***.*** deduped │ ├── @***@***.*** │ ├── @***@***.*** │ ├─┬ @***@***.*** │ │ ├── @***@***.*** deduped │ │ └─┬ ***@***.*** │ │ └── ***@***.*** │ └─┬ ***@***.*** │ └── ***@***.*** — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1751 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABlbrgQlrMLtOLWZVVF_9LfmNrw2fWYks5u7o6lgaJpZM4ZfFQj> .

[Holger-Will]

I will try to make a minimal test case. For now I was only able to reproduce the bug with serialport + websocket. Though it seems it does not depend on the websocket implementation. I tried ws, websocket, socket.io... I'm still not sure if a mock binding shows the same problem or if I have to get real data... What is the preferred data/parser for these minimal test cases?

[Holger-Will]

I could make an arduino sending random bytes to the port... That should be the easiest for everyone to reproduce...

[reconbot]

That would work

[Holger-Will]

i was able to reproduce the bug without any third party modules. it's quite easy for everyone to test.

const SerialPort = require('serialport')
const Readline = require('@serialport/parser-readline')

const port = new SerialPort('/dev/ttyACM0', { baudRate: 9600 })
const parser = port.pipe(new Readline())

parser.on('data', console.log)

setInterval(() => {}, 2000)

without the last line everything is fine. but when inserting the interval, data only comes in at the speed of the interval...

a complete setup including a simple arduino sketch can be cloned here: https://github.com/enocean-js/serialport-bug

[Holger-Will]

there is a related report on SO :
https://stackoverflow.com/questions/53892677/what-is-asynchronous-processing-when-using-settimeout

[shabunin]

Can confirm the issue. Tried with different nodejs versions, all the same.

serialport@6.2.2 works good, as expected. 7.0.2, 7.1.1 has this issue.

Holger-Will, thanks for interval hack.

[Holger-Will]

can this be labeled as bug?

[maxwellhadley]

I see the same issue with serialport 7.1.1 under NodeJS 8.12.0 on macOS 10.13.6 (High Sierra). It's as if the code that dispatches the received bytes into the JS environment is using the 'timers' thread, not the 'next tick' thread (or whatever the mechanism actually is).

[reconbot]

Yeah this is related to #1742 we will either release a fix or pull the release.

[Holger-Will]

i tried to confirm the fix, but now i'm getting a segfault with binding 2.0.5 whenever i try to open a port. probably a separate issue...