On 6/30/20 5:05 AM, aberba wrote:
On Monday, 29 June 2020 at 11:58:10 UTC, Steven Schveighoffer wrote:
and all you have to do is compose the pieces to get it to be a text
iopipe (an iopipe where the window type is a string type).
No sure I understand this statement.
What I mean is, no matter where your data comes from, you compose
iopipes together to get it to be a text iopipe (one that is comprised of
UTF code points), and then the json parser can handle it.
For instance, it could be zipped data on a network socket, it could be
data that comes from a segment of a file that you loaded into a local
buffer. It could even be data that is generated. As long as it provides
a mechanism to be read into a buffer (or is already in a buffer),
jsoniopipe can handle it.
This is one thing I think makes iopipe so useful -- you can compose them
together like you can compose ranges, and the end result is fully
optimized on all layers.
I'm not familiar with NodeJs in general so I can't comment on that. I
would say iopipe is focused on making streaming more like dealing with
arrays, with as high performance as possible. One thing I've always
disliked about most streaming libraries is that they hide the buffer
as an implementation detail, but it should be the focus.
How well does iopipe work in a multi-threaded environment?
I'm assuming you mean multiple threads using the same iopipe? It does
not have any implementation to handle something like that. You would
have to handle the locking yourself.
I plan at some point to write a full replacement for writeln and friends
using iopipe, which would necessarily have to deal with multiple
threads. I'm not sure whether the multithreading constructs would be put
into iopipe, or something else, I haven't thought enough about it.
Let me know if there's any other questions you have, either here or on
the github issues.
-Steve
