Actors that drive their own event processing (or maybe have idle processing)

[abingham]

As I currently understand Pykka actors, they are entirely event driven in the sense that they don't do anything unless they've received an event. What I'm looking for is a way to have an actor that "does things" all of the time, and which handles messages when it's ready.

The motivating example I've got is an actor which monitors a camera (say, a web cam), examining an image every second. When it detects a face in the image, it send a message to some other actor. The obvious (perhaps naive) approach to this is an actor that sits in a loop, taking pictures and, after each picture, explicitly letting events be processed. Something like this:

class CameraActor(pykka.Actor):
    . . .
   def process_events(self):
       if self.its_been_one_second():
           img = take_picture()
           if face_in_img(img): 
               self.target.tell({'face_rect': face_rect(img)})
       super().process_events()

Or something like that. Perhaps an "idle handler" is a better approach. The main point, though, is that I'd like the actor to be able to do processing even in the absence of any external stimulus, e.g. events.

I think I can simulate this currently by having the actor send messages to itself. This feels to me like a lot of ceremony for something that's conceptually simple.

I've looked briefly at Actor._actor_loop(), and this seems like the likely place to insert these kinds of changes.

In any case, hopefully you can understand what I'm looking for. Is something like this supported in Pykka already, or would it require changes? Maybe this is just a bad idea, but then I wonder how I should implement something like my CameraActor.

[jodal]

I think my own pragmatic solution would be to have a plain daemon thread which polls for an image, checks for faces, sends event to an actor for further processing, and sleeps until it is time to poll again.

Having an actor message itself (through self.actor_ref) is a useful trick for splitting up tasks that take a long time to complete, so that e.g. stop messages can be processed in the middle of a large task. Nobody likes their program to spend a minute on shutting down.

In a program with an event loop, like GLib, Twisted, or asyncio, the sleep part could be replaced with asking the event loop to call the poller regularly.

I want to bring Pykka to asyncio in the not too distant future, but have yet to think about if Pykka should have any abstraction for scheduling functions to be executed in the future by the asyncio event loop, or if you'll just have to use asyncio directly yourself for such use cases.

Do you know how this is solved in any other actor systems, like Akka?

[abingham]

I don't know about Akka. But in e.g. stackless, d, and go you have more explicit control over message processing, deciding when to pull messages from channels. D and go (but not stackless, for some reason) let you wait on messages with a timeout, so that makes it relatively easy to implement "sleep for a few seconds" without risking long shutdown times.

My sense is that a system with explicit message handling is more general than what pykka currently provides, and that pykka's current functionality could be implemented in terms of such a general system. But that's mostly just speculation right now; I haven't spent time trying to implement anything!

[drozzy]

Sending messages to yourself is exactly the right way of doing this.
In an Actor system actors cannot do anything out of their own will - they only respond to messages. This is what gives the guarantee that nothing will deadlock, or produce other concurrency issues (shared state etc..)
Here are two ways of handling sending messages to yourself:
http://doc.akka.io/docs/akka/2.3.6/scala/howto.html#scheduling-periodic-messages

The alternative is to manage the concurrency on your own, through thread scheduling or constant polling (which will tie-up 1 cpu 100% of the time anyways). Avoiding the former of these is the reason for me to pick actor-based system in the first place.

Also, nothing is stopping you from creating a plain "thread" with sleep functionality, or the class similar to the one in your example, which checks for new pictures, has a "reference" to an actor, and simply sends a message to an actor anytime new photo is available.

Finally, take a look at Futures vs Actors, and see if they may be relevant to you instead of actors:
http://doc.akka.io/docs/akka/2.3.6/scala/futures.html

[fjarri]

Sorry for raising an old question, but if I'm understanding correctly, this hasn't been resolved so far. I encountered the same problem, and the periodic messaging solution from the post above would indeed solve it - if this functionality was available in Pykka. Are there any plans to implement it?

[fjarri]

I made a draft PR for this feature, comments appreciated.