On 7/8/14 12:05 PM, Michael Behrisch wrote:
> Hi Tom,
>
> Am 05.07.2014 04:51, schrieb Thomas Lockhart:
>> I'm looking at the city_mobil runner.py and afaict it is having trouble
>> with the non-reentrant structure of the traci module. It does one run of
>> simpleManager.py and then tries to do the same thing with
>> activeManager.py. There are some problems with global variables in
>> vehicleControl.py and in statistics.py, and even after cleaning those up
>> it seems that traci has some additional globals which are not
>> initialized in the traci.init() call or reset in the traci.close() call.
>>
>> Any thoughts on whether this is a priority to fix in traci, or whether
>> we should restructure the runner script to ensure that the two test
>> cases are run in separate processes?
> I would say fixing the CityMobil scenario is not so high priority
> because the way the runner does it is not the usual use case, you would
> probably only start one manager.
> But I would say traci itself should be clean after the connection(s) are
> closed. Can you give an example on what goes wrong?
>
What I see is that the second instantiation ends immediately at step
zero with a message to the effect "at the request of TraCI". If I go
through and re-initialize some more of the globals defined in
traci/__init__.py, I can get it to end at 100 steps, which is an
explicit completion condition in the manager if the number of persons is
zero. But the expected behavior is that it runs for 3k or 4k steps,
which is what happens when that test case is run separately.
There must be more globals which need to be re-initialized, but I
haven't found them all yet.
In general, traci is implemented as a set of functions and module-wide
state variables, which means that there are variables which can not be
shared between traci connections without exposing side effects. If this
were implemented as a class then the state and temporary variables would
be encapsulated in the object and would be created anew when a new
object was created.
If this were desirable I would guess that this could be implemented as
an addition to the current features. Something like:
from traci import traci as TraCI
traci = TraCI()
traci.init(PORT)
# or traci = TraCI(PORT)
...
where I've made the code a bit obtuse to show how it could almost match
the current usage.
The module could possibly still allow the current usage:
import traci
traci.init(PORT)
...
possibly by implementing the init() function in the traci/__init__.py
file as
tglobal = None
...
def init(PORT):
tglobal = traci(PORT)
return
Let me know if a prototype implementation would be of interest.
- Tom
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
sumo-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sumo-user
