Replies: 2 comments 1 reply
-
Even on macos (with gnu coreutils) i am able to use I also have another request (timestamps) which is somewhat unrelated, I'll make it separately. |
Beta Was this translation helpful? Give feedback.
0 replies
-
All event writes in That however might not be the case with the older |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm intending to consume watchexec's events as streams from a node process. I am not too familiar with the ins and outs of stream buffering behavior but here's an example of how in terms of overall simplicity I would have to say that it looks like the producer should generally be the one responsible for performing fifo/pipe buffer flushing, since it's in control of the output.
The problem I'm having is that when I launch watchexec in this way to give the data to node,
Since i'm consuming this stdout, node will buffer that incoming data and invoke the callback when it decides it wants to, aka buffer reaches highwatermark or whatever, and not when an event arrives.
This behavior should be possible to mitigate from the sending side by explicitly flushing the output file descriptor as shown in the earlier link.
So I'm curious if we could consider a new option which takes a number of milliseconds to wait for events before flushing the output buffer when
emit-events-to
mode is used. This way, buffering can still be effective when events are streaming rapidly, but it allows us to receive individual events with a guaranteed maximum latency we control.At first I considered switching to using the file mode instead of the stdin mode, but I realized that this is probably going to have the same issue, possibly even worse, it will be the operating system that has control over when it wants to flush the most recently buffered events out to the file on disk, and only then will i be able to read them in from the consuming process.
I vaguely recall the ability in linux to pipe a program's output through something like stdbuf as a large hammer to modify stream buffering behavior. Maybe I can use that since each line of output is an event and line-buffering would at least get me to a usable place immediately. But that is probably not the ultimate solution.
Beta Was this translation helpful? Give feedback.
All reactions