iopipe v0.2.0 - safe update

[Steven Schveighoffer]

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