Hi stefp,

Maybe I'm just too pratical, but I think I'm the only person that isn't repulsed by Tk's appearance. I like programming in it and with a little effort you can make your stuff look pretty decent. Oh well, back to the matter at hand.

I might be missing something obvious here, but I would think the best way to get around this problem is to fork before dealing with Tk at all. That way the kiddie won't inherit any of the nasty X (or other wm) stuff. There are situations when that may not be easy, but for the most part I think it saves you.

Maybe if you gave us a better idea of what kind of stuff it was doing we could provide more useful information. But I think even if you have, say, a front end with buttons and each button when clicked forks a child to perform a given task, there really isn't any reason a preforked child couldn't get a message over IPC (or socket, I've become a huge fan of IO::Socket/IO::Select recently, mmmm) and just handle the task instead of forking again.

Anyway, please provide a bit more information - an example would be nice, perhaps. I'll stop back and look again as I'm sure other monks will.

Good luck,
{NULE}
--
http://www.nule.org

I have yet to identify the difference between this snippet which works as intended and my code.

Probably the position of the mainloop is instrumental Here, the mainloop is after the my $fnm = $top->FileSelect()->Show(); and it works nevertheless

 #! /usr/bin/perl
 use strict;
 use Socket;
 use Tk;
 use Tk::FileSelect;
 use FileHandle;

 my $top= MainWindow->new();
 my $txtw = $top->Text->pack();
 my $fnm = $top->FileSelect()->Show();
 my $rd = new FileHandle;
 my $wr = new FileHandle;
 pipe $rd, $wr;
 if ( fork() ) {
   $top->fileevent($rd,'readable',\&insert);
   MainLoop;
 } else {
   open I,$fnm;
   print $wr $_ while($_=<I>);
 }
[download]

-- stefp -- check out TeXmacs wiki

Update: I changed my mind on this - see my newest node at the end of the discussion.

Hey stefp,

Thanks for the example. I'm afraid I don't agree that the parent/child relationship can't be changed. I think in your shoes I would still be thinking about handling this with a pre-forked process. Or I would be trying to avoid the complexity of the parent/child as it is not clear to me the value that it provides.

I am probably going to butt out now, because without a better idea of why you cannot or are not willing to change the archetecture I can't be of much help. Would I be correct in thinking that this fork only happens once at the beginning of the process? I'm not saying you are wrong and you very well may be doing this the best way possible and if so I hope you can easily resolve your issues with the help of the monastery.

But before I butt out, let me ramble aimlessly for a bit. {g} If you must fork there are a few reasons why pre-forking a child strikes me as a good idea. First is it reduces process management issues. In your example you have no wait or waitpid which will eventually lead this process to fail if it is in a loop. With a single pre-forked child you can simple ask the child to exit and wait once at the end. It also makes signal handling less difficult (or perhaps just less critical).

If you are going to pre-fork, that child could just listen for a message from the parent saying "Get me this $file", and then the child reacts to that an passes the information pback over the socket pair and listen again for the next directive. It's different than what you are doing in your example, but depending upon what you are trying to accomplish it may be a cleaner way to do it.

Second, inheriting things like the Tk objects is obviously avoided if you pre-fork. This provides a savings in memory and in start-up time, particularly if the forking happens repeatedly. In an interactive program this may not be much of an issue since people are used to waiting for the hourglass so to speak.

Next, if the child isn't doing some tremendous value add stuff, forking at all doesn't seem to be helpful in this case (in fact it adds much complexity). The reason I see to fork is to better handle blocking issues but with a filehandle there are any number of ways in this issue in this. Using IO::Select on your filehandle in a loop lets you do processing and prevent blocking during your read process.

Well, anyway I wish you luck. If I think of anything helpful to add (as opposed to my babbling just now. :) ) I'll check back in.
{NULE}
--
http://www.nule.org

I hope in your actual code you have an exit() call in the child process.
Because if you don't, the child process will go back to the MainLoop after finishing with the while().
That won't happen in the example that you provided here, however.


# ...
} else {
   open I,$fnm;
   print $wr $_ while($_=<I>);
   exit(); # Stick this after all your code
}
[download]

--perlplexer

Wait a sec. When are you forking? From inside a button handler or something? If you're not forking before MainLoop there shouldn't be an issue, not in my experience anyway.

--
Ash OS durbatulk, ash OS gimbatul,
Ash OS thrakatulk, agh burzum-ishi krimpatul!
Uzg-Microsoft-ishi amal fauthut burguuli.

If I got things right, Gtk-Perl supports only gtk 1.2. In that version, I have not seen any nice Tk like text features like tags that permit to associate to specific text sections properties like fonts, colors or handlers. See Tk::Text

I would be happy to be proven wrong because this is the only thing that keep me using Tk. For example the Tk::FileSelect widget mapped but beeing totally blank for many seconds while readding a dir with many entries is enough to drive me mad.

Some references: gtk 1.2, gtk 2.0

The text stuff in 2.0 seems complex but interesting and includes a tag mechanism. This is a nice overview. I have no experience with this gtk text stuff in C. But existence of tags in gtk 2.0 is moot point if I stick to perl until gtk 2.0 is supported from perl.

-- stefp -- check out TeXmacs wiki

{NULE}
--
http://www.nule.org