search

jamesmunns / postcard-rpc

An RPC layer for postcard based protocols
Apache License 2.0
93 stars 22 forks source link

`spawn` is counterintuitive #28

Closed si14 closed 3 weeks ago

si14 commented 5 months ago

The spawn option is a bit unusual in how it works. Intuitively, it seems dangerous, since it doesn't surface the maximum number of tasks, so it might seem like it can exhaust resources. But of course it's limited by pool_size and can error out with SpawnError::Busy, and will do so by default if sent more than once in parallel (which is also not something I'd expect!).

On the other hand, it can be substituted with a handler that sends a message to a channel that tasks are reading from.

I'm happy to take a stab at a note in the docs describing this nuance, but an alternative would be ditching spawn altogether, incentivising users to just use channels+prespawned tasks instead. What do you think?

jamesmunns commented 5 months ago

I like spawn, and use it heavily in my projects. I am not currently interested in dropping it.

Open to docs PRs.

jamesmunns commented 3 weeks ago

I'm going to close this, but I am still open to docs PRs, or feel free to re-open if you'd like to discuss.