[GRASS5] display system

[Glynn Clements]

I've been looking into the problems with mon.start/XDRIVER which
necessitated the code which is conditionalised upon "#ifdef __W98__",
and have a few comments.

1. The problem seems to be specific to XDRIVER; the CELL driver works
fine if mon.start and src/display/devices/lib are build without
__W98__ defined.

2. The above makes sense; the Windows resources (e.g. the window)
created by Graph_Set() presumably aren't going to be inherited across
the fork() (certainly, POSIX/XPG*/Unix98 don't say anything about the
behaviour of fork() w.r.t. Windows resources).

3. This would apply equally to a "native" Windows or MacOS driver. X
is rather different because of X11's client-server architecture; the
only system resource held by an X client is the descriptor for the
connection to the X server.

4. Intuition says that __W98__ ought to be unnecessary when using the
vanilla XDRIVER under Cygwin with an X server. There have been
reported problems, although this could be a bug in Cygwin or Cygwin's
Xlib. Hard information would be welcome.

5. The existing (problematic) behaviour exists for a reason. Delaying
the "daemon-isation" (fork(), parent exit()s) until everything has
been initialised and the monitor is ready to accept connections
ensures that the monitor is ready as soon as mon.start terminates.

This ensures that the subsequent invocation of mon.select will succeed
even when mon.select is run immediately afterwards. It also explains
why, with the libW11 port, the first attempt to select the monitor
fails (and, if the initialisation were to take too long, the second
attempt would also fail).

So what, if anything, should we do about it?

One option would be to create the socket (socket, bind, listen), fork,
and only then call Graph_Set(). When R_open_driver() calls connect(),
that will succeed as long as the socket is actually listening, even if
the monitor is busy with Graph_Set() and doesn't actually accept() the
connection for a while (Graph_Set() can take quite a long time in some
situations).

Unfortunately, that doesn't work well with FIFOs, where you can't tell
the difference between a non-existent monitor and a monitor which is
taking its time to open its end of the FIFO.

Summary: the existing mechanism works well with X11, but can't be made
to work reliably with other window systems. The most obvious
alternative won't work well with FIFOs, but are these still important?

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