Reliable stream termination can be solved by tracking streams per portal, per nursery?

[goodboy]

As per #57 we need a system to help manage stream teardown, namely the explicit calling of StreamReceiveChannel.aclose() on either intentional stream termination by a consumer/producer or by the containing ActorNursery during its wait on all actors to complete or error phase.

what we've got right now:

• our tests that demonstrates what should be done by client code is manually calling aclose
• our context api (aka the push model) also doesn't have any explicit stream shutdown api from the producer end other then built-in cancellation machinery which I'm not even sure will do the right thing since there's no Portal instance normally on the called/producer side of a connection
• consumers interacting with a Portal should get all streams cancelled when the actor is cancelled which should happen when a nursery block is cancelled, however, if deamon actors are left running and are producers of streams it's theoretically possible that a nursery waiter task could spin for at least a second before terminating the stream; this could potentially be avoided by calling Portal.aclose() for any portal created by the current ActorNursery?

That last suggestion needs some thought; task-actor interaction in terms of how portals can be passed around between task versus actor nurseries is not clear to me yet.

[goodboy]

Actually hold up, if a push producer (using Context) exits its decorated function the client should be signalled that the stream stopped - which results in the local results channel being closed and thus subsequently in the IPC channel being cancelled.