FOTS: running the CLI in a separate process

[Sorin Marian Nasoi]

Both Cezar and Nicolai suggested using the process module for the FOTS driver.

Here is the potential problem: currently the FOTS driver uses the current version of Zorba for testing.
For a developer, this usually means a branch version of Zorba that may, in some cases cause some tests to SEG FAULT/HANG.
When running the FOTS driver this will also break because of the Zorba breaks.

A solution could be to call Zorba from a different process using the 'process' module. This way we could report something even for the tests that SEG FAULT and even for the tests that HANG by waiting for a limited amount of time for an answer.

There is however the issue of adding a dependency to the 'process' external module.

[Chris Hillery (ceejatec)]

Minutes from phone conversation on this issue Nov. 28:

We discussed three possible solutions:

1. Write a wrapper script (XQuery) around the existing FOTS driver which uses the process module to run the driver once for each test in a test set.

  Advantage: could be done entirely by Sorin immediately (Juan, Cezar and myself will likely be busy with XML Prague and other issues for at least another week).
  Disadvantages: slow; requires some duplicate work to produce reports. Also, since it uses the process module (a non-core module), it won't be usable by every Zorba user.

2. Extend XQXQ to have the ability to run a query in a forked process. Initially, it would only allow retrieving the process exit status; this would allow FOTS driver to "pre-run" each query to see if it crashes, and then run it again in the main process as it normally does. Later we could figure out a way to return successful query results back to the parent process, and FOTS driver could use them directly.

  Advantages: Eventually a clean and useful extension to XQXQ. Eventually would allow FOTS driver to run either in forking or non-forking mode with minimal overhead.
  Disadvantages: First stage is a pretty ugly hack. First stage would also be slow. Would require copying some code for cross-platform process forking from the process module. Would require time from Juan and/or Chris, and even first stage would probably be more development time than solution #1. Not clear whether the eventual second stage is even feasible (how can results from an Iterator be returned from a child process?).

3. Extend the FOTS driver to optionally utilize the process module to launch Zorba separately for each query.

  Advantages: Doesn't require additional module coding.
  Disadvantages: Unclear how to "optionally" import the process module (and it cannot require it since it is a non-core module). Slow. Would require fairly extensive modifications to FOTS driver since executing a query via the Zorba command line is very different than using XQXQ.

On the whole we decided that option #3 was not worth pursuing. Option #2 is the best long-term IF and only if it can actually be made to work; the first-stage half-solution option #2 approach is a very ugly and slow. We will investigate this option further, but in the short-term (next week) Sorin will work on implementing Option #1 and we will see if that meets our immediate needs.