On 07 Jul 2004 14:26:35 -0500, Rusty Phillips wrote:
>
> > > while($g==0) { } \
> >
> > This is endless loop.
>
> Actually it's not. The only thing that can make g==0 is another
> process. It's a locking mechanism to guarantee that only one copy of
> xwd is running at a time, because xwd is not thread safe. It's a hack.
> Watch the process listings while running this and you'll see that it
> works.
No, this is an incorrect explanation. This is endless loop. However
$g is never 0 here, so this loop is never entered. One process can't
modify the memory of another, there are no threads at all.
Here is a short explanation of how modules interact with fvwm on
SendToModule:
fvwm -> fvwm sends SendToModule argument to module -> module
and waits for answer if module asked so;
<- module may optionally send some commands <-
but usually it just immediatelly
<- sends unlock, so fvwm may continue further <-
however FvwmPerl does not itself unlock during eval,
so fvwm is synchronized with FvwmPerl by default;
to unlock fvwm, use unlock() or detach() functions
There are no threads, one main module process reads messages from fvwm.
If you unlock(), but not detach(), then what happens is fvwm may send the
next SendToModule message to a busy module, and noone will read it until
the previous eval is finished. If eval is finished within ModuleTimeout,
then module may read the new message from fvwm and unlock it, otherwise
the non-responding module is killed. After detach() the work is done in
the second process that should in no way affect the main one. In theory.
Regards,
Mikhael.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Wed Jul 07 2004 - 16:49:54 BST