jswelling
commented
6 years ago The obvious fix for this is not to sleep a thread when locking if it's not already awake- the error is happening during creation.
Open jswelling opened 6 years ago
jswelling
commented
6 years ago The obvious fix for this is not to sleep a thread when locking if it's not already awake- the error is happening during creation.
During a birth event the FacilityManager greenlet for the community creates a new patient. This ultimately calls peopleplaces.Person.init() which attempts to lock the new agent to the CommunityWard. If there are no available beds in the ward, when agent.MultiInteractant.lock() gets called it is forced into a clause that makes sure the thread trying to do the locking is the new Agent itself, which of course it isn't because this is happening during the FacilityManager's timeslice. This looks like a design problem that didn't show up until now because (a) births only happen in genericCommunity and (b) we're used to having spare beds in the community.
The stack trace looks like:
(Pdb) where /home/welling/git/quilt_github/src/quilt/peopleplaces.py(97)run() -> timeNow = self.handleRequest(req, logDebug, timeNow) /home/welling/git/pyRHEA_github/src/sim/pyrheabase.py(113)handleRequest() -> return super(FacilityManager, self).handleRequest(req, logDebug, timeNow) /home/welling/git/quilt_github/src/quilt/peopleplaces.py(75)handleRequest() -> return self.toManage.handleIncomingMsg(req.class, req.payload, timeNow) /home/welling/git/pyRHEAgithub/src/sim/facilitybase.py(541)handleIncomingMsg() -> a = PatientAgent('PatientAgent%s_birth' % ward._name, self.manager.patch, ward) /home/welling/git/pyRHEA_github/src/sim/facilitybase.py(767)init() -> pyrheabase.PatientAgent.init(self, name, patch, ward, timeNow=timeNow, debug=debug) /home/welling/git/pyRHEA_github/src/sim/pyrheabase.py(289)init() -> super(PatientAgent, self).init(name, patch, ward, debug=debug) /home/welling/git/quilt_github/src/quilt/peopleplaces.py(233)init() -> self._loc.lock(self)