# -*- mode: org -*- Archived entries from file /home/cwebber/org/xudd.org * Tasks ** DONE [[issue:6]] Make single-threaded Hive & move hive.py to threadedhive.py CLOSED: [2013-07-27 Sat 16:30] :PROPERTIES: :ARCHIVE_TIME: 2013-07-27 Sat 16:31 :ARCHIVE_FILE: ~/org/xudd.org :ARCHIVE_OLPATH: Tasks :ARCHIVE_CATEGORY: xudd :ARCHIVE_TODO: DONE :END: *** DONE Think through some of the things CLOSED: [2013-07-27 Sat 16:30] **** Hive as an actor Why not make the hive itself an actor? *** DONE Move everything to deques CLOSED: [2013-07-27 Sat 16:30] ** CANCELED Fix [[issue:4]] CLOSED: [2013-07-27 Sat 16:30] :PROPERTIES: :ARCHIVE_TIME: 2013-07-27 Sat 16:31 :ARCHIVE_FILE: ~/org/xudd.org :ARCHIVE_OLPATH: Tasks :ARCHIVE_CATEGORY: xudd :ARCHIVE_TODO: CANCELED :END: *** Think it through *** CANCELED Fix it CLOSED: [2013-07-27 Sat 16:30] **** CANCELED UniqueQueue attempt CLOSED: [2013-07-22 Mon 18:34] Let's try the stupidest version first. **** CANCELED Event attempt CLOSED: [2013-07-22 Mon 18:34] Event on the actor, in_queue - Can ONLY be set to False by the hive worker (when the actor really is removed from the queue) - Can ONLY be set to True by the hive. (either when message is being added to the queue or on possible respooling request) **** CANCELED pubsub attempt CLOSED: [2013-07-27 Sat 16:30] *** CANCELED Make sure you add proper docstrings CLOSED: [2013-07-27 Sat 16:30] ** DONE Write out prototype CLOSED: [2013-07-27 Sat 16:31] :PROPERTIES: :ARCHIVE_TIME: 2013-07-27 Sat 16:31 :ARCHIVE_FILE: ~/org/xudd.org :ARCHIVE_OLPATH: Tasks :ARCHIVE_CATEGORY: xudd :ARCHIVE_TODO: DONE :END: *** DONE Hive CLOSED: [2013-07-27 Sat 16:31] file:~/devel/xudd/xudd/hive.py **** DONE Hive workers CLOSED: [2013-07-19 Fri 16:01] ***** Thinking it through ****** Queue of actors (with a queue of messages) Let's type through the situation we'd *like* to code out. - The key of the registry probably should contain a tuple of: (Actor, ActorQueue) - Adding a message to an ActorQueue - The HiveWorker adding messages to the ActorQueue - Removing an actor from the queue altogether (what if when messages waiting?) - Should the hive be its own thread? - An actor is taken off the queue. Two objects: - the actor_queue - an actor's message_queue ****** Queue of messages ***** DONE Lock-danger-free option CLOSED: [2013-07-19 Fri 16:00] ****** Thinking it through - The hive itself becomes a thread. When started, it spawns the worker threadpool - Move message queue onto the actor itself - New queue on the hive: "ActionQueue". Two types of actions for it for now: - queue a message - check to see if an actor should be re-added to the queue - Does there need to be any locking? I guess there needs to be a lock on an actor's message queue since a worker thread might pop an item off it, and you want to make sure not at the same time that it's being checked for re-adding by the hive. But that's the only case, and there shouldn't be any deadlock risks. Stupid race conditions! At least it's easier this time. - Simple action setup for now... tuples: ("check_queue_actor", Actor) ("queue_message", Message) Note to self: suggested that Hive itself be an actor that handles its own messages... Aeva facepalmed :D ****** DONE Add HiveProxy CLOSED: [2013-07-19 Fri 16:00] ****** DONE Switch queue over to actor.queue CLOSED: [2013-07-19 Fri 16:00] ****** DONE Switch Hive to be a master thread that spawns other threads CLOSED: [2013-07-19 Fri 16:00] ****** DONE Add main loop, which includes queueing messages CLOSED: [2013-07-19 Fri 16:00] **** DONE Hive actor registry CLOSED: [2013-07-19 Fri 16:02] **** DONE Sending messages CLOSED: [2013-07-27 Sat 16:31] ***** DONE On the hive end CLOSED: [2013-07-27 Sat 16:31] Okay, what's the API for this? ***** DONE Yielded sending method on the actor CLOSED: [2013-07-27 Sat 16:31] **** DONE Creating actors and the HiveProxy CLOSED: [2013-07-27 Sat 16:31] How is an actor created? And how does it get access to the HiveProxy? Two options: - The main hive can always be responsible for creating actors, and it can be done like so: #+BEGIN_SRC python class Hive(): def create_actor(self, actor_class, *args, **kwargs): actor = actor_class( self.gen_proxy(), *args, **kwargs) # other things... actor_id = hive.create_actor( SomeActorClass, *args, **kwargs) #+END_SRC I think the above route is probably the best route... it prevents actors from having "too much access" to the other actors they create. *** DONE Actors CLOSED: [2013-07-19 Fri 16:02] **** DONE Basic message handling CLOSED: [2013-07-19 Fri 16:02] *** DONE Robot Scanner CLOSED: [2013-07-27 Sat 16:31] file:~/devel/xudd/xudd/demos/robotscanner.py **** General plan here's my idea of a first test scenario there's a security robot that's supposed to go into a warehouse and go from room to room and look for infected droids to keep it simple, each room only has two doors and they're all in sequence like [ ]->[ ]->[ ]->[ ] so the security robot is able to send a code that reveals whether the droid is infected, and if so, it needs to keep firing shots at it until the malicious droid explodes. after every room cleared it reports back to its overseer so the pattern when entering a room is like: - ask the room the addresses of the robots - while not all robots dead: - fire shots at all infected robots - report back to overseer - move on to next room (if exists) sound like a good test? and to test the yield thing, that whole implementation will be done as one function on the actor. not a complicated test, but maybe a good start? mmm I'm open to other tests as well sounds good this makes me think I should revive swarmlib :) I'd love to see the designs of swarmlib **** DONE Design draft code CLOSED: [2013-07-19 Fri 16:59] **** DONE Get it to run CLOSED: [2013-07-27 Sat 16:31] ** DONE Put up infrastructure CLOSED: [2013-07-18 Thu 14:03] :PROPERTIES: :ARCHIVE_TIME: 2013-07-27 Sat 16:31 :ARCHIVE_FILE: ~/org/xudd.org :ARCHIVE_OLPATH: Tasks :ARCHIVE_CATEGORY: xudd :ARCHIVE_TODO: DONE :END: *** DONE Toss it on GitHub CLOSED: [2013-07-18 Thu 11:12] *** DONE Put up docs on ReadTheDocs CLOSED: [2013-07-18 Thu 11:40] ** DONE Properly stop all threads on KeyboardInterrupt CLOSED: [2013-07-20 Sat 14:31] :PROPERTIES: :ARCHIVE_TIME: 2013-07-27 Sat 16:31 :ARCHIVE_FILE: ~/org/xudd.org :ARCHIVE_OLPATH: Tasks :ARCHIVE_CATEGORY: xudd :ARCHIVE_TODO: DONE :END: ** DONE Do first draft thinking of hive CLOSED: [2013-07-20 Sat 14:32] :PROPERTIES: :ARCHIVE_TIME: 2013-07-27 Sat 16:31 :ARCHIVE_FILE: ~/org/xudd.org :ARCHIVE_OLPATH: Tasks :ARCHIVE_CATEGORY: xudd :ARCHIVE_TODO: DONE :END: *** DONE Idea braindump CLOSED: [2013-07-20 Sat 14:32] *** DONE Theoretical code examples CLOSED: [2013-07-20 Sat 14:32] ** DONE "responding" to yields CLOSED: [2013-07-28 Sun 12:18] :PROPERTIES: :ARCHIVE_TIME: 2013-07-28 Sun 12:18 :ARCHIVE_FILE: ~/org/xudd.org :ARCHIVE_OLPATH: Tasks :ARCHIVE_CATEGORY: xudd :ARCHIVE_TODO: DONE :END: *** Thinking it through We shouldn't let coroutines which send out messages dangle in the registry... they deserve a response if they request one! As such, I think if a message is sent with a "yield" via self.wait_on_message(), it should add a awaiting_response=True field. We should prevent "stuck coroutines". We can do this via a couple of methods: - coroutine timeouts. Optionally when doing self.wait_on_message, allow for setting a timeout. In the default actor's handle_message() it could call a cleanup at the end always. - We can have the wrapped Message() object and handle_message() of the receiving actor conspire together to help make sure *some* sort of response is given. This should happen via three parts: - There's a message.reply() tool (constructed appropriately by the hive) that you can use. If you do this, it'll consider the situation resolved. - If you intend to send a reply later, you can do message.defer_reply() and that indicates that your actor will give a reply at some future, unspecified time. - If neither of those is true either by the end of the function or by the next yield, the default handler provides a polite, simple acknowledgement that's just "ack_response" (or "handled_response", or similar). The response is basically empty, but it allows the original sender to know their message is being handled in some shape or form. *** DONE message.reply() tool? CLOSED: [2013-07-28 Sun 12:18] I tried to do this with actor.reply_to_message() but it doesn't handle the defer_reply() bit. Plus it loses a bit of DRY.