Robert Nagy
Robert Nagy
I'm not sure I agree. It only waits for it to be ready not to finish pending async writes (writing).
If you add the following assertion then the test suite will fail: ```patch index 45bf86d..2d4f8a2 100644 --- a/index.js +++ b/index.js @@ -8,6 +8,7 @@ const path = require('path') const BUSY_WRITE_TIMEOUT...
no editorconfig or prettier? 😢
> We rely on this feature when shutting down the logger during `process.on('exit')`: in this case the write will _never_ finish, so we can't wait. Possibly this is ok, the...
> Could you add a test? Mocking is ok. Sure. Was hoping the assertion would be sufficient (tests fail now without the fix). But I can do a test as...
> I don't think you can make the assumption that the consumer is faster. We already kind of do that https://github.com/pinojs/thread-stream/blob/main/index.js#L218. My suggestion is missing `'drain'` atm. I can sort...
Updated with drain
```js const assert = require('assert') const EE = require('events') const WRITE_INDEX = 4 const READ_INDEX = 8 const HWM = 16 * 1024 async function* read({ sharedState, sharedBuffer }) {...
> IMHO 90% of the complexity comes when avoiding the blocking on the writer, moreover it's the first requirement of this system. If we are blocking the main thread, we...
We can polyfill `Atomics.asyncWait` in node 14.