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
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
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.
Your team Zorba Coders is subscribed to branch lp:zorba/process-module.
Mailing list: https://launchpad.net/~zorba-coders
Post to : email@example.com
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp