[WritableStream] Locking semantics

[tyoshino]

For ReadableStream, we specified the lock to be releasable only when there's no pending read().

For WritableStream, what should we do? While any write() is pending (returned promise is pending), a writer shouldn't be releasable? This means that while the queue is not empty, a writer cannot be released.

So, the queuing mechanism serves to single consumer. Does this sound right?

[domenic]

Hmm. I don't see many advantages to adding this restriction.

Part of the advantage of having a writable stream is to allow "fire and forget" writing: write(), write(), write(), write(), then go do something else. Maybe "something else" is close(), maybe it is releaseLock() and let someone else start their writing.

I would rather allow releasing the lock with pending writes, and just have further writes from a new exclusive writer go to the same queue.

[tyoshino]

Agreed. So, I'll change the locking to allow releasing writer with pending write()s.

Then, we can say that on both ReadableStream and WritableStream a lock is unreleasable while there's pending operation on the internal queue. WritableStream doesn't have any async operation regarding the queue, and therefore a lock can be released anytime.

BTW, was there any good reason for which we made the readable stream lock unreleasable? reader.closed must become unavailable to allow the next lock acquirer to hide state, but pending read() can be fulfilled remotely without any concern?

[domenic]

I think our reasoning is that that was likely to be a programming error, but I am not sure...

[tyoshino]

I think our reasoning is that that was likely to be a programming error, but I am not sure...

OK... Me neither.

We could relax ReadableStream's constraint, too if it turns out to be useful.

In #488, I've relaxed the constraint for WritableStream. Not the WritableStreamDefaultWriter's releaseLock() doesn't check whether there're pending writes or not. I've added a TODO in the OP to document the difference between RS and WS.