-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can the output buffer be inspected to see if its clogging up? #69
Comments
Writes are only buffered within a single event loop tick. The write
callback can be used to know when it’s been submitted to the OS. The drain
function can be used to wait for the os to finish writing.
On Fri, Aug 2, 2019 at 5:41 PM Kyle Kienapfel ***@***.***> wrote:
I didn't notice anything when I was poking at the WritableStream object,
but I think it would be useful to be able to know how much is in the buffer
before writing out a request for a status.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#69?email_source=notifications&email_token=AAAGK3XDOGYUBT7RTYQRTVLQCSSYLA5CNFSM4IJBG73KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDEYTKA>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAGK3TE33S6IVHN53TOOY3QCSSYLANCNFSM4IJBG73A>
.
--
---
Francis Gulotta
wizard@roborooter.com
|
I'm still thinking through what the actual specification text will look like but at a high level there are three buffers in both the read and write directions:
The buffers for read work similarly, but transfer data in the opposite direction. What is left out of this a way to ensure that data has been written out of the hardware buffers. In the POSIX API this is tcdrain(3). I am planning on mapping this to the WritableStream's None of this is implemented yet in Chromium and is tracked by issues 989653 and 989656. I'm reluctant to add a method to measure the amount of queued data because it is inherently racy given that the buffers are constantly being drained by the UART. I'm curious whether given the design above you would still also need a method to query this. Edited to add: Lots of buffering isn't great. I recommend applications avoid buffering lots of data in the WritableStream by always awaiting the Promise returned by |
I apologize I got my repos confused and was referring to node serialport. Node serialports drain waits for all stream level writes and does a tcdrain call. Which sounds quite similar to what you’re thinking. |
Thanks, I'll look more closely at the promises. It is quite possible my issue would be solved by looking at timers, and promises a bit more closely. Actually with the age of the codebase I'm looking at, it's quite possible that it's been solved, and the commands looking at the buffer never got removed... |
Since my comment above the buffer flushing and purging behavior I mentioned above has been implemented. Calling As for determining the amount of data that is currently queued for transmission there is still work left to do. As specified the |
I didn't notice anything when I was poking at the WritableStream object, but I think it would be useful to be able to know how much is in the buffer before writing out a request for a status.
The text was updated successfully, but these errors were encountered: