[winGRASS] [GRASS5] display system

[Malcolm Blue]

Glynn,

The need for the "#ifdef __W98__" was only to support the Windows 98
implementation of Cygwin.  Althought the XDRIVER worked fine on Windows NT
and Windows 2000, the implementation of fork() in the cygwin library did not
work properly under Win 98.  I was able to isolate the problem to the fork()
call, which in testing worked very inconsistently.

The Cygwin faq does (or did) identify issues with fork().  The solution that
I implemented (and Mike Thomas had committed to the CVS) was to spawn the
child process from mon.start rather than fork() within the XDriver (as
implemented in devices/lib/main.c).

The problems that I identified with fork() on Win98 were not consistent with
each test.  Sometimes the child appeared to start, othertimes not.  It
always seemed to die before the monitor was started, which may be caused by
the problem with inheriting windows resources.  I suspect it is related to
Win 98's poor support for threads/process management.  If I remember
correctly, the process id and parent process id were not consistently
handled during the tests, either.

The bottom line is that fork() does work OK on WinNT and Windows 2000, but
not on Win98 (unless the Cygwin implementation of fork() has been fixed).
The __W98__ fix is not needed for all cygwin users, just for Win98. Any
changes you make will have to take into account the limitations of Win98,
but don't necessarily have to be in the same for all Cygwin users.


HTH,

Malcolm


-----Original Message-----
From: wingrass-admin at grass.itc.it [mailto:wingrass-admin at grass.itc.it]On
Behalf Of Glynn Clements
Sent: Friday, January 11, 2002 4:06 PM
To: grass5 at grass.itc.it; wingrass at grass.itc.it
Subject: [winGRASS] [GRASS5] display system



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>
_______________________________________________
winGRASS mailing list
winGRASS at grass.itc.it
http://grass.itc.it/mailman/listinfo/wingrass