Actor & AsyncChannel instead of lock/serialize

[malhal]

In ForkedResource I wondered if you considered using actor instead of lock with the serialize func?

Also how about AsyncChannel instead of the continuations array? AsyncChannel Is great way to communicate between tasks.

[drewmccormack]

The very first thing I considered was whether to make an actor, or just a Sendable class. The problem I had with an actor is it then forces everyone down the async/await path, and could even introduce more race conditions than it solves.

To me ForkedResource feels like a lower level thing, which you could use inside of your actors, rather than an actor itself.

I have an app that uses an actor for the Store, and I regret it deeply. Hope to replace it soon with this package. It is just riddled with uncertainties, because every suspension point is a potential race condition.

So my preference is definitely to stick with a Sendable class, which can be used even by people not adopting async/await. And if people want an actor, it is trivial to wrap a ForkedResource in an actor. (It might be an idea just to provide a ForkedActor type which is a simple wrapper around ForkedResource for those who want that.)

As for AsyncChannel, I am not that at home with it. I haven't used it before, and am not familiar.

I just "solved" the observation problem by allowing people to ask for a changeStream, and they can then put that in a for loop. The ForkedResource tracks the open streams, and messages each. If AsyncChannel is a better solution for this problem, I'm open to it.