feat(core): streams

[AaronO]

This allows resources to be "streams" by implementing read/write/shutdown, returning None if not implemented and Some(future) otherwise.

These streams are implicit since their nature (read/write/duplex) isn't known until called, but we could easily add another method to explicitly tag resources as streams.

op_read/op_write/op_shutdown are now builtin ops provided by deno_core

Note: this current implementation is simple & straightforward but it results in an additional alloc per read/write call

Closes #12556

[piscisaureus]

I am pretty certain that boxing the returned future is unavoidable with trait methods.
It'd be nice though if we could avoid double boxing.

[bartlomieju]

What about sync APIs?

[AaronO]

What about sync APIs?

Since sync APIs are only used for file IO (on StdFileResource) I was planning to rename them to op_fread_sync, op_fwrite_sync, I don't think those sync APIs should be in core given that they're only used for files and we don't have any other obvious implementors for now.

This would leave them out from IO metrics in core, but this is easy to reconsider down the line

[bartlomieju]

What about sync APIs?

Since sync APIs are only use for file IO (on StdFileResource) I was planning to rename them to op_fread_sync, op_fwrite_sync, I don't think those sync APIs should be in core

Okay, keep in mind that StdFileResource is used for stdio too.

[piscisaureus]

I still don't see why these ops should return Option<AsyncResult<_>> rather than AsyncResult<_>.
IMO that's just un-ergonomic and the "op not supported by this resource type" case really doesn't need any optimization.
Or am I missing something?

[AaronO]

I still don't see why these ops should return Option<AsyncResult<_>> rather than AsyncResult<_>. IMO that's just un-ergonomic and the "op not supported by this resource type" case really doesn't need any optimization. Or am I missing something?

I think the "ergonomics" of the trait weren't a priority for a first pass given the limited amount of callers. The plan was to tweak and evolve this. I still generally don't like the idea that we have to peek into errors to know if the stream was readable or not. But regardless I've dropped the Option<...> from the trait in the latest commit

[piscisaureus]

LGTM!