Hi 2 all,
i spend a lot of time in investigating this problem, but i will give up
on this.
I'll describe my findings in the hope that someone with more background
on Linux system programming can help us.
I used ddd with a non-stripped build of the whole GRASS source to look
at the behaviour of d.mon -L/-l, start/stop, which call the programs
mon.status, mon.start, mon.stop etc.
I can circumcise the problem in the function fifoto in
src/libes/raster/io.c.
The idea with the fifoto function is that the fifos for reading and
writing are opened, and if can be opened, the x driver is running. If a
timeout occurs (i. e. the open blocks), the driver is not running or has
lost connection.
This is done as follows:
no_mon = 0; /* global variable is reset to signal that no monitor is
running */
sigalarm = signal(SIGALRM, dead); /* SIGALRM is set to call a own
function dead,
which does nothing than setting no_mon to 1 */
alarm(alarm_time); /* shedule the alarm to come in in alarm_time seconds
*/
_wfd = open(output, O_WRONLY); /* open the fifo, if timeout occurs, the
alarm function will cancel */
alarm(0); /* cancel/reset the alarm function */
if (no_mon) /* monitor is not listening on this fifo */
return 0;
The same is repeated for the reading fifo.
This seems to work on IRIX (what about BSD and Solaris, would be
interested in hearing from users of those systems), but on Linux the
open call hangs forever. The man page for open on IRIX describes
explicitly this form of testing if an other process is listening on a
fifo. If you use O_WRONLY & O_NONBLOCK or O_WRONLY & O_NDELAY, the open
process should not block.
There are two problems with this function:
1) There could be a race condition between the alarm call and the open
call. But this should not matter as the process should never be blocked
longer than the alarm period.
2) If system calls are restarted automatically, the open call is not
interrupted with the SIGALARM handler returning. So the open hangs
forever. This is IMHO the problem here.
One other problem is that in the original code not O_RDONLY/O_WRONLY,
but 0/1 are used.
I tried already to implement this with setjmp/longjmp calls, but i could
not get this to work either. The monitor starts, but the selection of
the monitor fails alltogether.
The removing of the lockfile is not the culprit, as i can test with
IRIX. If i kill a monitor, the lockfile is not removed there either. But
if i have a monitor running (x0) and i run "d.mon start=x0" the module
exits with the message "monitor x0 already running", while with Linux
the module blocks forever (in the open call in fifoto).
With the IPC setup the fifoto function does not use a timeout (and never
checks if the monitor is not open). I have no idea how this works.
And i think we really need to merge together the fifo and IPC code, so
that we can recompile with a compiler switch and some #ifdefs in the
source. The way it is now (switching by copying files from different
directories) is not usable. And i have not found a solution how i can
use the IPC setup on Cygwin/Win32 in the first run. Compiling the whole
source and issuing ./README.ipc -cantrememberflags and to recompile the
whole thing is impractical.
Please feel free to comment on this,
Andreas
Markus Neteler wrote:
Hi Andreas,
On Wed, Nov 29, 2000 at 02:06:41PM +0100, Andreas Lange wrote:
> Hi Markus, Hi Justin,
>
> you can close the grass monitor on Linux with the "Kill" option too (i
> use a lesstif/motif window manager on linux that has the
> IRIX-look-and-feel). But you can not restart the same (x0..) driver
> again, as the lockfile is not removed.
Yes, that's right. The left-over lock file is causing troubles.
Suggestion: Maybe a check could be added like this:
- lock file found
- check if monitor process is (still) running
- yes: lock
- no: remove the lock file, start monitor
- lock file not found
- start monitor
I did not look into the code, but maybe this is a way to get rid
of the problem.
> On the SGI i can close the monitor with close or exit (mouse) and
> re-open it again.
Helena reported as well that SGI users don't face this problem (lucky
people!)
> This all seems to be for the same reason that d.mon -L does not work on
> linux. I see now that i was looking in the wrong place (SWITCHER.c), the
> problem must be somewhere in the code that checks for the monitors
> running. There must be a timeout/deadlock, as d.mon -L hangs forever if
> it encounters a running monitor.
> This may be because some system call have other semantics on linux than
> on commercial unix.
Sidenote: If you use the IPC based driver, the d.mon -L is working (on
Linux). With fifos it doesn't. Maybe helpful? So only the IPC-modified
files might be related to this problem (probably reduces the number of files
to be checked).
> I'll look into this, until now i can only close the monitor on linux and
> re-open it after i call d.mon -L once. This produces an error message
> and the lock seems to be gone.
>
> cu,
>
> Andreas
Yours
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
