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 [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
