02:01 <SeanTAllen> johshoff: hopefully we get you excited sometime!

19:24 <Sargun> Is there a mechanism to preempt an actor, or to wait on an actor to die?

19:26 <jemc> Sargun: can you elaborate a bit on what you mean by "preempt"?

19:26 <SeanTAllen> Sargun: the scheduler is cooperative, no way to preempt. An actor can run up to its batch size (100) of messages (behavior calls) and the next actor will be scheduled.

19:27 <SeanTAllen> Re: die... I suspect because i know your background you are thinking of Pony actors like Erlang actors which isn't really the case. What are you looking to do/accomplish Sargun?

19:27 <jemc> for the latter question - the only way to know when an actor "dies" is to have it send you a message when it finishes whatever it was doing, or when someone calls `dispose` on it, if you're using that pattern - in other words, it has to be a message at the application level

19:28 <jemc> note that actors can't "crash" in the erlang sense - they can only be "stopped" by finishing the work they were doing, or being "disposed" to disengage them from whatever open-ended work they were doing

19:29 <jemc> (or whatever other application-level messaging pattern you can think up - but those are the most common ones)

19:30 <Sargun> SeanTAllen: I'm trying to determine whether there is a way to check if a "tree" of actors is finished

19:30 <Sargun> So, like I have 5 requests in progress, and I want to ensure they do not progress any further

19:30 <Sargun> effectively, I want to "join" against them

19:31 <SeanTAllen> So when all five are done, change the state of something and move to the next phase?

19:31 <Sargun> They're effectively "heartbeat" threads

19:31 <Sargun> So, I want to kill the heartbeat actors, and then send a shutdown message

19:32 <SeanTAllen> actors will be "killed" by the runtime when they can no longer receive messages. which means no other actors hold references to them and they arent registered for any async io events.

19:33 <SeanTAllen> the standard pony pattern is to implement "dispose" on an actor and send it a "dispose" message when you want it to shutdown so it can close files, sockets, or whatever

19:33 <SeanTAllen> it will be reaped by the the runtime once there are no more references to it and its not able to otherwise receive messages

19:35 <jemc> Sargun: for that pattern, it sounds like you could look at using `Promise`s, and `Promises.join`

19:35 <jemc> there are more direct ways to acheive it than promises, which are probably the most decoupled way

19:46 <Sargun> Hrm. I'll continue to experiment

19:46 <Sargun> I'm trying to decide whether to choose Pony or Nim for a project

19:47 <Sargun> I don't really need green threads -- thread counts should be <1000

19:47 <Sargun> but, I need strong safety guarantees

19:47 <Sargun> I'm prototyping a locking server replacement to one that's originally written in Go

19:50 <SeanTAllen> Sargun: im confused by the green threads comment.

19:50 <SeanTAllen> Not sure where you are going with that

19:50 <SeanTAllen> By default, the pony runtime will create 1 scheduler thread per CPU and schedule actors on the schedulers using a work stealing algo.

19:51 <SeanTAllen> Additionally there is a main thread that does nothing but wait for the scheduler threads to exit (it does a join on them) and a thread for dispatching async io events.

19:51 <SeanTAllen> There's no green threads at least not under my definition of green thread.

19:55 <jemc> I think a pony actor can kind of be thought of as a "green thread plus", but that's not necessarily the most accurate or productive definition - just a nice place to start for people who are used to thinking of threads

20:02 <jemc> a locking server sounds like a nice use case for pony's strengths

20:23 <SeanTAllen> indeed it does