Added a notion of closing for streams/buffers/stdio:
This allows a producer or consumer of a stream/buffer to indicate that there is no more data to write (for writable), or that it's no longer interested in the data (for readable), so that the consumer/producer on the other end can stop writing/reading.
This is critical for filter-like execs.
The notion of closing right now is just a function call and a corresponding event: it doesn't yet go as far tracking the state of the stream/buffer at all times; and the event can theoretically be fired multiple times.
I think that to take it further, stdio, streams and buffers should be made proper Ephemerals.
I haven't completely solved the chicken and egg problem where, for example, buffers create streams: it the owned stream gets closed by the client, should the owning buffer close as well? What about the opposite? I've implemented some logic, but I'm not yet 100% sure it's right. We could iterate on this.
After the first redirection PR, Wash.prototype.dispatch and ExecuteContext.prototype.setCallee ended up created two levels of NestedStdio: after adding the notion of closing for streams, that created problems with various parties listening to onClose on one or the other of this two nested NestedStdios.
Saving both stdio and its individual streams on ExecuteContext creating an aliasing problem: nothing prevented the client from directly resetting one and getting the whole set out of sync (happened to me during debugging). I'd prefer to keep just the stdio member; however, there we so much usage of stdin etc. in the code, that I decided to do the opposite for now.
Added exe/sort.js (used it as a testing tool).
I'll add more comments directly in the code changes tomorrow.
@rpaquay
Again, sorry for the large PR :)
Some notes:
Ephemerals
.onClose
on one or the other of this two nestedNestedStdio
s.stdio
and its individual streams onExecuteContext
creating an aliasing problem: nothing prevented the client from directly resetting one and getting the whole set out of sync (happened to me during debugging). I'd prefer to keep just thestdio
member; however, there we so much usage ofstdin
etc. in the code, that I decided to do the opposite for now.I'll add more comments directly in the code changes tomorrow.