On 19 Apr 2002 19:02:52 +0000, Mikhael Goikhman wrote:
>
> On 19 Apr 2002 14:09:18 +0100, Tim Phipps wrote:
> >
> > [EMAIL PROTECTED] wrote:
> >
> > > On 18 Apr 2002 13:46:21 -0600, Gregg Dameron wrote:
> > >
> > > > Bottom line - PipeRead is brilliant, indispensable - I'd like to see
> > > > itbe more so.
> > >
> > > My guess is that calling many shell utilities (read: many processes)
> > > is sometimes more expensive than one perl script doing the work.
> > >
> > > Moreover in pre-2.5.1 you may embed perl in fvwmrc without any
> > > additional processes to be called at all. You should only start
> > > FvwmPerl once and do 'SendToModule FvwmPerl eval perl-code' as many
> > > times as you want.
> >
> > Does this operate synchronously? One of the main reasons I use PipeRead
> > is to do maths in fvwm functions i.e.:
> >
> > PipeRead "bash -c 'echo some_fvwm_function $(($w * 10))'"
> > which will call some function with the windowid times 10. If FvwmPerl
> > could do this it would be very useful to me
>
> It is not synchronous currently. Sometimes you may like to do the work in
> parallel with fvwm. I will solve this problem, but I want to do it in the
> perl library, so it may take some time to do this properly. Also, I see at
> least 5 different ways to specify this in the FvwmPerl syntax (using new
> messages, config options, command line options, perl functions in "eval"
> to turn synchronization on and off dynamically).
Ok, now FvwmPerl actions ("eval", "load" etc.) are synchronous by default.
You should be careful, so your action is not too long otherwise it should
be killed. Since it is synchronous, some operations are forbidden.
For example, try this code:
ModuleSynchronous FvwmPerl
SendToModule FvwmPerl eval system("xmessage abc")
This creates deadlock between fvwm and FvwmPerl (fvwm waits for unlock and
FvwmPerl waits for mapping and then closing xmessage), so FvwmPerl is
killed after a timeout of 30 seconds. This is better:
SendToModule FvwmPerl eval unlock(); system("xmessage abc")
This runs xmessage asynchronously, so there is no deadlock. However, since
system() is blocking, you can't send more actions to FvwmPerl until you
close xmessage window. So if you repeat the previous line and don't close
the first xmessage in 30 seconds, FvwmPerl is killed again.
Just for this situation I introduced detach() that forks FvwmPerl.
-SendToModule FvwmPerl eval detach(); system("xmessage $version")
-SendToModule FvwmPerl eval $a = $prefix; detach(); system("xmessage $a")
-SendToModule FvwmPerl eval command("Exec xmessage $a/bin/fvwm")
You get 3 xmessage windows in separate processes (the last one is spawn by
the fvwm child, the first two - by FvwmPerl childs), so FvwmPerl is free
to listen to more actions.
I hope now you understand better synchronization issues and FvwmPerl.
Tell me if there are still uses for PipeRead that FvwmPerl doesn't solve.
Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
