Closed alexcrichton closed 1 year ago
I believe we should leave whatever blocking-
family functions in that are convenient for users for preview2. For preview3, we expect all of this to go away and be replaced by component model primitives. So, there isn't much we should plan to change here.
This has been addressed by #45 and #53. We now have a set of blocking functions which provide a simple API for blocking use cases, including a check-write
mechanism.
I wanted to log a discussion I had with some folks recently (cc @lukewagner, @sunfishcode, @pchickey, @elliottt) where we were talking about the
blocking-*
family of functions present on the streams interface.Attempting to summarize the discussion, my impression was that the functions were originally added for convenience for examples/tutorials/getting started/etc, but with the recent developments around writes and flush happening on https://github.com/bytecodealliance/wasmtime/pull/6877 the story there was a bit more unclear and a
blocking-write
function is less obvious than before.One option was to enhance/updated the
blocking-*
functions to do "what you might expect" e.g. bundling acheck-write
or things like that. The other option though was to go the other way and remove the convenienceblocking-*
functions for now and optionally add them back in later.We figured that no changes should probably be done in the preview2 time frame but we would want to consider changes for a later time frame.