Hacker News Reader

Comment by oersted | Hacker News Reader

I was looking forward to checking out Project Tina until I realised it was a completely different language. Classic story. Surely you can build a thread-per-core message passing concurrency framework in Rust, the language is designed to allow such alternatives.

Is Project Tina a bit like the Actor Model, but having actors pinned to cores?

And I don't understand how Tina deals better with the problem of compute-heavy tasks blocking the thread. It looks to me like it is also cooperative concurrency per core, and if one Isolate runs for a long time the other Isolates in that core will not be able to handle their messages.

View on HN

I'm not 100% sure, but it looks like Tina forces your IO to be return values. You can't actually do IO inside the Isolate handlers, so your compute code runs and returns the next IO operation to run. That's what it meant by you need to be explicit about the state machine, you have to have a handler for before I make this IO, and a handler for after that IO has run.

Isolates are like synchronous state machines. During each handler invocation, an isolate processes one message, mutates its private state, and chooses its next scheduler action. If IO is needed, it returns an IO Effect describing the IO, the isolate is parked, and the eventual IO result is delivered through a later completion message. In the meantime it continues to handle messages of other isolates.

Edit: And I realized you asked about compute-heavy tasks, nevermind, it does not seem to solve that.

That does clarify some things, but still. Say you have an Isolate pinned to a core and it's doing some long compute. In the meantime some background IO finished and an Isolate in the same core needs to handle the result. That will not happen until the long compute is done.

Isn't it just like in async and any other cooperative concurrency model? At least in multi-core async, that message can be handled in a different core so it's not completely stuck. But sure the author doesn't like that work-stealing cost happening automatically outside of their control, fair enough.

Correct, the claim here is that this is better because cache locality is too big a hit and not worth the trade off. I don't know if this is true or not and likely depends on workload.

I think they might say you need to rewrite your long-compute to have explicit yield points. Say you are parsing many rows, you'd explicitly yield after every 100 rows for example.

Reply on news.ycombinator.com