ZSDC,
I love this stuff! You explain these concepts very clearly, have you ever
considered teaching? I'm happy to keep asking questions as long as you're
willing to answer them. =)
> Servers often work this way. There's a process listening on a port but
> when someone connects, it doesn't serve the actual request (which would
> block the server and no one else could connect until it's done) but only
> forks the child, which then serves the request, and the parent keeps
> listening for another requests and forks another children at the same time.
Neat! Is this how "threads" are spawned? or are forked processes different
from threads?
If this is how threads are spawned, how do big commercial apps manage to do
multiple things at once without completely duplicating the entire executable
in RAM? or is Perl's implementation less robust than the one used for
C++-type apps?
> As for the client side, you could for example have a mail client
> downloading mail in the background, while the user can keep writing and
> sending mail at the same time, etc. Check out this example:
>
> #!/usr/bin/perl -w
> open F, '+>', "$0-result" or die $!;
What is '+>'? I've never seen that before.
> defined(my $pid = fork) or die $!;
> unless ($pid) {
> # child:
> sleep 5; # an important time consuming task...
> print F "123\n";
> exit;
> }
> # parent:
> print "Not yet... Do something else.\n" and sleep 1 until -s F;
I haven't seen the '-s F' notation either -- is it a -x file test?
> Yes. Actually, there's a whole genealogy tree. The process with ID 1
> (usually called init) is the protoplast of every other process running
> on the system. This is the only process without a parent.
>
> The killing of children makes sense when e.g. I open an xterm window and
> run "man fork". What I have now is a shell process which is a child of
> xterm, a man process which is a child of the shell and a pager (for
> scrolling man's output) which is a child of man. Now, when I just close
> the xterm window, the pager, man and shell are killed as well. It makes
> sense, because keeping them running (sleeping, actually) would be pointless.
This is all starting to make sense now... Thank you!
> But sometimes you don't want that. For example, your ssh connection
> could die, everything is killed and you have to connect and login once
> again and start everything from the beginning. If you don't want that,
> then check out this great little program:
Once you background a run in a shell, though, it seems to keep running, at
least on our SGIs. How does that work? For example, I set a complex model
running with:
% itods myfile.txt &
Now if I exit the shell, the process keeps going. How does that fit in?
>> What is a session? I've never heard of that...
>
> A session is basically (it's an oversimplification) a bunch of processes
> which get killed if you close the session, because they are important
> only for that session (like the example with xterm). For more
> informations see:
>
> man setsid
> http://linux.ctyme.com/man/man2993.htm
>
> man getsid
> http://linux.ctyme.com/man/man0960.htm
>
> man setpgid
> http://linux.ctyme.com/man/man2984.htm
Nice!
> I'm glad I could be helpful. This subject usually causes lots of
> confusion. I hope others could also find it interesting and didn't mind
> if I was a little bit off topic.
Thanks again.
- Bryan
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
