On 06 Jul 2004 18:49:24 -0500, Rusty Phillips wrote:
>
> Okay, comments about that script:
Please write to the list, not to me directly.
> 1) I had named pipes on the brain. This statement works just as well,
> and is smaller. Good idea.
> eval $e = `xwd -silent -id $[w.id]`
>
> 2) Actually, I tried using detach first. It crashed FvwmPerl for me.
> On the other hand, forking didn't. That's the reason I used it in my
> scriptlet.
I may try to suggest a fix if I see the problematic code. Was FvwmPerl
killed by fvwm for exceeding the ModuleTimeout? This would indicate your
code problem.
> 3) As to putting it in an external script, I didn't do that as Scott
> suggested because I wanted to make use of named pipes (as opposed to
> writing a temp file, thus wasting more time), and I wouldn't get them if
> I had it in an external script unless I made two of them and did some
> interprocess communication. I didn't want to resort to that.
>
> 4) There shouldn't be a bottleneck because it forks (creates new
> processes), just as it would if you were using an external script.
>
> 5) "Don't expect any random fork() to work in FvwmPerl"
> Why not? Won't it do a good job if you fork and exit like I did?
> What sort of problems can I expect?
In your solution you manually fork FvwmPerl. I don't see where you stop()
the child. So, it seems like you create a new FvwmPerl child on every
iconification. Internal detach() implements the forking correctly.
> I was under the impression that FvwmPerl used pipes to communicate with
> fvwm, and those are inherited by child processes.
Yes, but when 2 processes write to the same pipe, bad things may happen.
So, forking is not something you may do freely.
detach() may usually work, but unix pipes are not that safe on fork. So,
if you want to be safe, use a single FvwmPerl process with or without
unlock(), you don't really need concurrency, you should just be faster
than ModuleTimeout. Alternativelly, create a new module that creates
thumbnails on iconify events. Just keep in mind that there are always one
read and one write pipe to fvwm behind the scenes. So, you may fork short
children, but only the main process should read/write to fvwm if you
really want to be safe. You may need your own event loop then to
communicate with children and fvwm. Or maybe use signals from children,
but then unix signals are not that safe either and may interrupt pipe
sysread in the middle... But there is the light, you just should find it.
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 Tue Jul 06 2004 - 20:07:40 BST