This PR removes immediately triggered requests also immediately from resource queues. In current simpy master this happens later, once the request gets processed, which causes inconsistencies as reported in issue #62.
We require only a very limited interface from resource queues, what makes the removal somewhat difficult. I chose to change the interface by adding __len__() and pop() and removing the costly remove(). All existing queue implementations are based on list so that doesn't matter in simpy's code.
Suggestions for keeping the old interface are welcome. If there aren't any, I vote for merge.
Now that you bring that up, I think I remember that we already implemented the behavior of Ontje's PR in an older version of SimPy and fixed to the current behavior. However, I can’t remember why we did it. But maybe I’m wrong.
I interpreted it differently. My expectation was that the request event was yielded to the environment and would return when it could be accommodated. However as you now explain it, the semantics of the yield is more like joining with a Thread (I have java background). This behavior seems equally valid, it's just not what I expected. But knowing this, I can work around it.
I see. I think the closest match in the java world are futures. I think value = yield evt would almost be semantically identical to Object value = future.get(); (except of course, yield will not block the current thread).
I assume the discussion is favorable for the PR, so far. If Stefan doesn't find the revision and nobody speaks up, I'll merge later this week.