Subject: Re: FVWM: large PipeReads

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 19 Apr 2002 11:34:47 +0000

On 18 Apr 2002 13:46:21 -0600, Gregg Dameron wrote:
> 
> My motivation is to minimize disk reads after the configuration is
> loaded.  True, reading and executing a short script from disk is a small
> price to pay; on an idle system you'd never know the difference.  But
> the system here on which fvwm runs tends to be anything but idle.  When
> interactive performance gets sluggish, our users get cranky.
> 
> Bottom line - PipeRead is brilliant, indispensable - I'd like to see it
> be more so.

Well, if you want to get the maximal performance you should do some
benchmarks that are machine dependent.

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.
The line size limit is not important since you may store the state between
different calls to FvwmPerl. So you may have in .fvwm2rc the following:

  # All these commands may be called either in StartFunction or outside
  Module FvwmPerl

  # find all background pixmaps for a later use
  SendToModule FvwmPerl eval $a = $ENV{HOME} . "/bg"; opendir DIR, $a; @b = grep { /xpm$/ } readdir(DIR); closedir DIR
  ...
  # build a menu of background pixmaps
  AddToMenu MyBackgrounds "My Backgrounds" Title
  SendToModule FvwmPerl eval foreach $b (@b) { command("AddToMenu MyBackgrounds '$b' Exec exec xpmroot $a/$b") }
  ...
  # choose a random background to load on start-up
  SendToModule FvwmPerl eval command("AddToFunc InitFunction + I Exec exec xpmroot $a/" . $b[int(random(@b))])

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-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Fri, 19 Apr 2002 14:09:18 +0100

[email-masked] wrote:

>>Bottom line - PipeRead is brilliant, indispensable - I'd like to see itbe more so.
>>
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 (even though I'd have to 
learn perl first :-\ )

Cheers,
Tim.

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 19 Apr 2002 19:02:52 +0000

On 19 Apr 2002 14:09:18 +0100, Tim Phipps wrote:
> 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).

> (even though I'd have to learn perl first :-\ )

I learned it 7 years ago using man pages. You may start with perlsyn(1),
perlop(1), perldata(1) and then continue with perlfunc(1), perlvar(1),
perlmod(1) and other 150 supplied man pages. :)

And of course, one of the ways to learn perl is to patch FvwmPerl.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Fri, 19 Apr 2002 15:14:25 -0400

> perlmod(1) and other 150 supplied man pages. :)

I learned it the same way, although I did borrow someone's Camel
book for a few hours once.

I'd just like to add, that I think the effort is entirely worthwhile.

Lately I've been using GtkPerl.  Its pretty neat. 

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 30 Apr 2002 01:52:31 +0000

On 19 Apr 2002 19:02:52 +0000, Mikhael Goikhman wrote:
> > > 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.
> > 

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.