search

marcoonroad / sporadic

Composable Concurrency Abstractions for JavaScript. :railway_track: :rhinoceros: :train: :vertical_traffic_light:
https://sporadic.marcoonroad.dev
MIT License
18 stars 3 forks source link

Inconsistent way to close communication abstractions #1

Closed marcoonroad closed 5 years ago

marcoonroad commented 5 years ago

While the stream abstraction provides a custom value (mostly an Error) to close itself, the Error for the channel abstraction is hard-coded and fixed for close operations. The differences are shown below:

Stream's close operation: https://github.com/marcoonroad/sporadic/blob/b664f9fa2d931c3ba47fb0e710cf70c2e385778b/src/sporadic/streams/index.js#L68-L82

Channel's close operation: https://github.com/marcoonroad/sporadic/blob/b664f9fa2d931c3ba47fb0e710cf70c2e385778b/src/sporadic/channels/index.js#L77-L88

I should fix that. The API for close operations must be the same. If I allow the user to provide custom Error messages, there may be a non-determinism / race condition to break/throw such abstractions. If I fix the Error messages as hard-coded ones, all abstractions would deterministically break, the close operation here would be idempotent.

I should think carefully in such design tradeoffs therefore.

marcoonroad commented 5 years ago

BUMP:

The close operation should be deterministic and somehow idempotent. If the producer wishes to break consumers, it could send/publish Error objects and make consumers fail due that by implementing an internal handling logic.