Actually, I was unable to get the XDriver under Win98, and seem to have remembered Mike's problem incorrectly, since it was the CELL driver he was testing. It was a while ago that I had tested this, before your socket driver, so things may have changed.
I seem to remember that 'd.mon start=x0' thought the XDriver started, i.e. no error messages with 'd.mon -s start=x0', but when I checked the processes, the XDriver was not running. The errors occurred in 'd.mon select=x0' or in 'd.mon start=x0'. Since d.mon start=x0, includes both start and select, this is consistent. By this point the XDriver is in the process list for linux and cygwin/NT4.
I will put in some checks around the fork() call to see what is happening. This seems to behave much differently on Win98 than on NT4. As Mike says, the Cygwin docs describe a 'dodgey' way of implementing fork(). I may test my suspicions by substituting one of the spawn calls, but only to prove my suspicions and report the problem back to Cygwin list.
I don't think that this is the same problem as you report, but this is something to check out.
Thanks for the info,
Malcolm
Eric G. Miller wrote:
On Wed, Mar 28, 2001 at 01:59:45PM +1000, Mike Thomas wrote:
Hi Malcolm.
I will test again on Win98. I had suspected the fork() implementation.
My memory is that I wasn't able to get the CELL driver working on '98 at the
time, which backs up your suspicion!
I can imagine that given the complexity of the Grass drivers compared to a
small test program, it may well still be fork(). I was reading about how
the Cygwin people implemented fork() yesterday and it sounds dodgey. Maybe
Grass does something relating to program state that the test program doesn't
highlight.
I tried different socket communication modes for the CELL driver, without
success, in case it was sockets causing the problem.
So, the Xdriver works but the CELL driver doesn't? My understanding is
the fork() call may be the problem. Under all the GRASS drivers, there
is a call to fork() followed by the parent process exiting with the
child left running. However, if fork() fails, the driver will exit. Do
you get any error messages that might give a clue? Does the process
hang or just exit or what?
Also note, a failure report from d.mon that it was unable to set-up the
communications channel to the driver does not necessarily mean the
driver failed to start. Right now, there is a little timing problem
with the server getting to a listening state before d.mon gives up
trying to say "hi!". I've seen this problem more frequently with the
CELL driver as it seems to have a longer start-up cycle than the
Xdriver. Anyway, if this is remotely possible then after d.mon reports
failure, just rerun it with "d.mon select=CELL". I suspect that the
Cygwin fork adds even more overhead/slowdown for the driver than it
would otherwise have on *nix (where fork is pretty lightweight).
Anyway, I hope to hack a little on d.mon shortly to make it wait a
little longer or try a few more times to connect before giving up.
---------------------------------------- If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'