zorba-coders team mailing list archive

[Nicolae Brinza <nbrinza@xxxxxxxxx>]

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.