Regarding the referenced URI messages -- these are indeed coming from the 
StringPool as leaked entries. When the main process is fork()'ed, the child 
process is basically a copy of the parent process with all the statically 
allocated objects duplicated. When the child process calls exit(), those 
objects are destroyed. 

Since Zorba doesn't go through a normal shutdown, the StringPool still contains 
those entries and it prints the error messages and even throws an error. As a 
result the exit code of the process that was executed is actually lost. Even if 
the StringPool errors are bypassed somehow, another error is raised in the 
Lock() class. 

This problem was present in 1.0 version as well. The root of the problem is the 
bad design of engine and store instantiation: they are static singletons which 
require explicit calls to shutdown. 

Some possible solutions are:
1) Call abort() instead of exit() -- this will bypass all the static object 
destruction but I will need to find a way to pass the exit code to the parent 
process.

2) Pass the engine and store pointers to the process module and down to the 
child process so that it can call shutdown on them. This has the added problem 
of shutting down the store twice -- it is not an issue for an in-memory store, 
but could be for other stores.






-- 
https://code.launchpad.net/~zorba-coders/zorba/process-2/+merge/164415
Your team Zorba Coders is subscribed to branch lp:zorba/process-module.

-- 
Mailing list: https://launchpad.net/~zorba-coders
Post to     : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help   : https://help.launchpad.net/ListHelp

Reply via email to