Kuba Ober wrote:

> Tell you what. The amount of time this discussion has taken so far I
> presume is comparable to what it takes to use the working and tested
> QProcess. And this will work on Windows (for those who compile LyX
> with Qt/Win) as well.
> 
> What's so bad about QProcess?

You really want to know?

(In truth I know nothing about QProcess. I did investigate 
QEventLoop though.)

1. QEventLoop is specific to Qt >= 3.1.
2. Qt < 3.1 must use a timer with timeout set to 0.
Together these two mean a lot of nasty #ifdef nastiness. 
See the sample code I posted here:

http://article.gmane.org/gmane.editors.lyx.devel:34552

3. I have to hack the event loops in all of the different frontends 
to get it to work. That ends up as a *lot* of code.
4. At least for Qt < 3.1 the event loop is permanently busy even 
when no events are present.
5. I could replace all that nastiness by using the timeout that 
we already use to blink the cursor (or is that a bark ;-).

Result is within the main event loop automatically and the code 
is trivial:

+       if (buffer_) {
                screen().toggleCursor(*bv_);
+
+               // Use this opportunity to deal with any child 
+               // processes that have finished but are waiting
+               // to communicate this fact to the rest of LyX.
+               ForkedcallsController & fcc = ForkedcallsController::get();
+               if (fcc.processesCompleted())
+                       fcc.handleCompletedProcesses();
+       }
+
        cursor_timeout.restart();
 }

Note that this is frontend-agnostic. It 'just works'. It will also
do so on Win32.

All the noise has been concerned with the 'other end' of the 
handling in which we use the handler connected to a SIGCHLD
signal to reap the zombie and to fill a global store with the
pid and status of the completed child process. It's quite hard to do
that *safely* and not helped by the fact that I was learning as I went.

This part will not work on Win32 but it is now maximally efficient
and elegant on a Posix system.

I guess that the Win32 code will use a timer to periodically check
whether any child processes have been completed, but really I know
nothing about Win32. Any insights welcome.

> No offense meant :)

None taken.

> Cheers, Kuba

-- 
Angus

Reply via email to