[GRASS5] GRASS Monitor

[Malcolm Blue]

Thanks Eric,

This confirms the suggestion from Markus - based on some of your earlier comments
- that the error messages I got on my Win98 port were from a timing problem.
BTW, I cc'd you on that response (from the winGRASS list).  This timely (no pun
intended) coincidence, saved me from further investigation.

My Win98 computer has a faster CPU (PIII 500MHz) than my WinNT box ( PII 300MHz),
which didn't generate the error messages using the same code changes as I was
testing on Win98.  Different OS, but exactly the same situation as Bob describes.

I'll try your sleep() suggestion for now, since by the second select attempt the
socket was detected on my machine.  I suggest we try the select a couple of times
with a sleep in between, before printing the message.  If it fails after a short
delay, then print the error message, try once more and then exit.  Rather than
lengthening the sleep, we could vary the number of attempts before alarming the
user.

Cheers,

Malcolm

"Eric G. Miller" wrote:

> On Tue, Apr 17, 2001 at 02:43:22PM -0300, Bob Covill wrote:
> > Hello,
> >
> > This is probably a question for Eric.
> >
> > I have a recent version of GRASS on Linux (RedHat 6.1). The system is
> > 300 MHz with 200 MB RAM. Everything works fine on this system.
> >
> > I then moved the GRASS build to a faster machine (PIII with 500 MB RAM)
> > also running RedHat Linux. Again, everything worked fine with the
> > exception of the monitor. The monitor (sockets) would start but complain
> > that the socket was unavailable or in use by another program.
> >
> > I discovered the source of the problem was that d.mon was trying to
> > select the monitor before it had completely started. I was able to work
> > around the problem by executing "d.mon -s start=x0" followed by "d.mon
> > select=x0".
> >
> > Any thoughts on why this might be happening?
>
> Nail on head.  Faster machine, executes more code during time slice,
> oops socket or server is not ready to accept connections.  Anyway, 'bout
> the only thing I can think of is to have d.mon sleep() for a little
> while before trying to connect or after the first attempt failing.  It
> may be a little trial an error to decide how many seconds and/or if the
> iterations of "try" should be increased.  One second after first failure
> might be sufficient.  I only know that the CELL/PNG drivers are much
> slower to start up than the X driver.
>
> If I wanted to get tricky, I would try to find out if the monitor is
> running from the process list and try harder to connect if it is, or
> just quit right away if it isn't.  But I think the sleep() hack should
> be sufficient.
>
> grass/src/display/d.mon/cmd/main.c
>
> ..
> 128     if (select->answer)
> 129     {
> 130         oops = run("select", select->answer); /* couldn't select */
> 131         if (oops && start->answer && strcmp (start->answer,
>                 select->answer) == 0) /* try once more */
> 132         {
> 133             fprintf (stderr, "Problem selecting %s. Will try
>                         once more\n", select->answer);
> +++             sleep(1);
> 134             oops = run("select", select->answer); /* couldn't
>                         select */
> 135         }
> ..
>
> P.S. Sorry, been a bit distracted from GRASS lately...
>
> --
> Eric G. Miller <egm2 at jps.net>
>
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'


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