[GRASS5] hunting KDE/Xdriver redraw problem

Glynn Clements glynn.clements at virgin.net
Wed May 16 10:41:35 EDT 2001


Eric G. Miller wrote:

> > I think that XDRIVER will have to do proper process management. The
> > existing code is really just proof-of-concept.
> 
> What do you mean?  Do you have some idea how the XDRIVER could possibly
> manage the behavior of the external programs that instigate the drawing
> operations?  

It can keep track of whether they are still running.

At present, XDRIVER does a double fork() so that it can forget all
about the long-lived redraw process; it only has to wait for the
short-lived intermediate process (to reap it, so that it doesn't
become a zombie).

What I'm suggesting is to revert to a single fork, so that the redraw
process is a child of the main process. The parent would periodically
use waitpid() with the WNOHANG flag to check whether the child has
finished yet.

This would allow it to inhibit spawning another redraw process before
the previous one had completed.

The other part of my previous suggestion, namely restricting
connections to redraw commands while the redraw was in operation,
turns out to be a bit more complex than I had initially allowed for. 

The actual clients will be children of the redraw process, and hence
grandchildren of the main process. There isn't any straightforward way
for the main process to recognise its grandchildren (recognising a
child is easy; it's pid matches the return value from fork()).

The simplest approach which I can see would be for the child process
to spawn the individual redraw commands with fork() and exec(), so
that it obtains their pids, and then pass these up to the parent
through a pipe.

This is starting to get messy, and it's of no use if the OS doesn't
support getsockopt(SO_PEERCREDS). And it's only necessary if we are
concerned about other clients trying to connect to XDRIVER whilst a
redraw is in progress.

-- 
Glynn Clements <glynn.clements at virgin.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list