[GRASS5] Re: installation/compiling instruction for GRASS on

[Malcolm Blue]

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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'