{"shas":[["3c7d500922306497f5063fecfca70bcdf1eac266","39b76599b8180a4e18d82cce43d7507d8dff8114@gmail.com","Wrap synchronous method dispatch in a fiber. Celluloid now requires 1.9\n\nThe initial release of Celluloid suffered from a pretty nasty problem/bug.\nSynchronous calls work fine so long as the actors in a call chain are all\nunique (e.g. A calls B calls C). However, if the call chain ever loops back\naround to the same actor (e.g. A calls B calls A) a deadlock occurs. A is\nblocked waiting for a response from B, so it never realizes B called it.\nMeanwhile B has asked A to handle a call and starts blocking waiting from\na response from A. DEADLOCK!\n\nHow can this be fixed? The only solution is to allow A to continue to service\nmethod calls even though the method it is currently dispatching is blocked\nwaiting for a call response. If A could take another request while it's waiting\nfor a call response from B, it could in turn service the new request B just\nmade, and unblock the entire call chain.\n\nTo accomplish this, we need to wrap the call in a fiber. Whenever an actor\nmakes a synchronous call to another actor, the fiber can yield, and the\nactor can wait for the call response as it processes additional incoming\nmethod calls. As soon as the call response is received, the fiber is resumed,\nand method execution continues. Actors remain sequential and only process one\nmethod at a time, but switch back and forth between running methods whenever\nsynchronous calls are made to other actors.\n\nWith this approach in Celluloid, you no longer have any control of the\norder methods are executed in. Several actors (each running in their own thread)\nmay be making method calls at the same time. The receivers process them in\na first come, first served manner, but if the receiver makes another outgoing\ncall, the actor suspends the method it's processing and moves on to the next\nrequest.\n\nThe end result is you may just need to be a little more vigilant when working\nwith instance variables. Other methods need to work with that state too, so keep\nit consistent. Don't mutate an object into an inconsistent state then make a\nmethod call. In general, try to preserve a class invariant.\n\nDon't write sloppy code with implementation logic coupled together between\nmethods through instance variables. Treat instance variables as the state of\nthe object, not a temporary space for passing state between method calls.\nThat's what the stack is for.\n\nIf you do that, which I hope you're doing anyway, then everything should be fine\nand concurrent objects Celluloid's actors provide should continue functioning as\nplain old Ruby objects with awesome concurrent and asynchronous capabilities.","Tony Arcieri"],["92bd1dfb8444d167816fe663e8aa6f13ec92dfbe","39b76599b8180a4e18d82cce43d7507d8dff8114@gmail.com","Add a (presently failing) spec for circular method calls","Tony Arcieri"],["f292c4319855bd72f5dfedc742df8855dc9bdd2f","39b76599b8180a4e18d82cce43d7507d8dff8114@gmail.com","Implement Celluloid.actor?","Tony Arcieri"],["5aff7909cd91ebef3344bac9f550b1e522811479","39b76599b8180a4e18d82cce43d7507d8dff8114@gmail.com","Include object_id in Mailbox#inspect","Tony Arcieri"],["f8a8316f0a830cf373d97fe4d80967b0f17be780","39b76599b8180a4e18d82cce43d7507d8dff8114@gmail.com","Yield the method call fiber when making outgoing calls\n\nThis has the inadvertent side effect of breaking all of the supervisor specs.\nNeed to figure out why.","Tony Arcieri"],["818d3ecbe1b8cd669699734b0d996a9e61670ef3","39b76599b8180a4e18d82cce43d7507d8dff8114@gmail.com","Wrap exit event handling in a fiber in case exit handlers call actors","Tony Arcieri"]],"ref":"refs/heads/master","size":6,"head":"818d3ecbe1b8cd669699734b0d996a9e61670ef3","push_id":34372225}