The Answer Gang

By Jim Dennis, Karl-Heinz Herrmann, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!

---

Parent and Child

The birth and death of linux processes

From tag

Answered By: Jim Dennis, Heather Stern

[Heather] Jim handed me a rough sketch earlier this month, and I figured the resulting discussion would be worthy of our readers.

Once again, I'm teaching a class on shell and Linux basics to a group and after many years of doing it I'm really getting tired of drawing the same old pictures on the whiteboard or flipsheets.

What we need is a nice drawing of this, something animated. Maybe you could whip something up in Flash, and tuck yet another feather in the webmastery cap?

[Heather] Well, poking around for Flash on Freshmeat.net finds a few zillion apps, (Ha, only 120. I've gotten worse from single keyword searches before.) Some have nothing to do with a certain media format at all... flash cards, flash RAM

Now tossing out all the things that are apps written in Flash, libraries to make it work at all, and front-ends for the Flash viewer we have... ahhh... Generators won't do, I want this to have our images in it. Dancing text alone is worse than the old MARQUEE and BLINK tags. Oh, there we go. Some alpha quality sourceforge projects to convert various formats into flash.

Package system search time. bzzzt Hmm, guess I'll have to fetch the sources and debug why they don't just './configure; make; make install' in my copious spare time.

/me buys Wilbur the GIMP some coffee, munches on a few doughnuts, and jumps merrily back into the world of animated GIFs.

Ok. So here's what I envision, About 12 slides, on a roughly square picture, as follows.

1) initial process. A rectangle somewhat toward the mid-upper left, saying "process"

[Heather] Well, if it's going to be a little mini movie, it needs a title, so let's start of with "The Process Model" and have the word "process" wander up there.

2) system call.

The giant word fork() appears over the process. Transition: process memory map.

System calls look nice in a monospace font so we'll have that pop out at the viewer, then fade out again as it highlights the edge of the process.

3) fork results.

Show the child - a similar sized process - seperating from the parent and the two being labelled, parent and child.

The copying process shows a thinner dark blue rectangle moving to its new location, then growing another process of the same size. Looks very spiffy.

4) zoom!

Make the parent smaller and give the child most of the right hand side of the picture.

Zooming's a little more work, but I can do that.

5) details.

The parent just says "parent", the child shows a memory map breakdown. From bottom to top... environment, text (code), BSS, and sharing a space where each grows toward center - heap and stack.

6) system call. The giant word exec() floats up...

I have a bit of fun with setting up the memory map, and this doodle you offered me has the exec() coming off the stack/heap area. I made it come out of the text (code) area and it looks better as well as not bumping into things.

7) result point 1.

The process space is cleared entirely, except the environment. This is, of course, the space which bash' "export" command moves variables into so they will be inherited, just to bring up one clear example.

result point 2.

The child now has its own fresh copies of the other parts, but highlight the inherited environment.

I show a wash of green as the child process replaces the forked clone with new material. For you readers, in Linux the fork() is really just a special case of the clone() system call, which can clone things a number of ways. Anyways, it's an easy highlight for the environment this way, at least assuming the viewer isn't color blind. Oops. I didn't think of how to handle that. I'll have to test with desaturation... but let me finish the pictures first.

9) zoom back out. Bring the parent and child back to their previous sizes.

10) meanwhile...

The parent exhibits the wait() system call. Now this could be blocking, or not blocking, I can spend quite a while on this part, but let's just make the drawing assume a blocking wait.

11) which waits until... The child does an exit() call.

The wait() call actually needs to hang around while the child lives since you're blocking, so scribble scribble that'll really read: wait() blocked. I'll have to make the child do something brief and cute (goodness knows what) then exit() leaving... uhh...

12) the child dies. Highlight the parent, which unblocks as it catches a SIGCHLD signal.

My first shot at this shows exit() turning into SIGCHLD, and the child process' border fading out.

That's not really right; init generates SIGCHLD after cleaning up most of the mess. And the dead child shouldn't hang around. We'll need to show the remaining process table, too. Make the kernel float in from offside so we can see that, perhaps.

My second shot (good enough for your first of several classes) shows the child process decaying to a partial border, the word "child" becoming SIGCHLD, and going into the wait() which clears.

Here's where the doodle breaks down, so time to re-doodle it, using the facts. The exit leaves a return code. But as you and I know, return codes aren't stored in the "dead body" of the child process. It only exists as a zombie - an entry in the process table, which is the only thing left of it after init sweeps away the main process. The process table itself is in the kernel somewhere. So I'm going to need to plot where to sneak in a kernel page. (I imagine a bag of popcorn... ) Doing that suggests having it show while the fork() is spawning the child too, so I can show the process id changing, and the parent's id assigned into ppid.

Yes, that will work much better. Let's get the animation between slides in, then fix up the last part and it's good to go. I found you a nice gif to flash translator, which we can try on the resulting file for grins.

I don't suppose GIMP can output flash yet?

Oooh, I will need to google for that Probably not. The GIMP's a raster image editor, and SWF is a vector based format. OTOH if the converter you're talking about is any good, maybe it can be merged onto the GIMP.

I'm sure there are more aspects of the process creation and lifecycle that can be drawn. I'm juggling a few things, but I'll post the drawing in progress...

Just stuff them in SysadMoin on the page TaosLinuxTraining, at least at the moment. When I'm happier with the parts you can split them up into several images - one per stopping point in our final form. We'll split the Process Model commentary onto a new page, and the world can have some fun with it.

Wiki rocks. Chalkboards and whiteboards of the world, unite!

Sysadmoin is our house wiki, used for our system administration natter. (http://www.starshine.org/sysadmoin) It's based on moinmoin, and I'm pleased to say that our dark theme is actually part of the upstream sources. Very pleased, after all the trouble I went to in order to http://www.starshine.org/sysadmoin/MakeMoinMoinDark in older revisions. The moin people are very active in development, so for this project at least, it's worth popping into #moin on freenode. Helps to show up on European hours though.

Maybe I'll even post the xcf file and let people enjoy paging around in it. I realize xcf isn't readable by anythign but gimp, but that's where the real animation lies, in the seperated frames.

For you dithering vidiots out there, frames of about 50 milliseconds distances seem to be fairly smooth going, slower's a little more obvious but somewhere between that and 140 ms are good for skidding to a halt. Anything slower is painful. Your eyeballs may vary, but recall that american TV is about 24 or 28 frames a second, and more is better. 50ms is a mere 20 frames per. I just don't want my file to get too big.

For gimp folk specifically, adding (50ms)(replace) to the end of the name of your frame gives fine grain control on the animation. You could use (combine) instead when you need it. And gimp does let you resize layers down again (it's tricky) which might save space in the result. The last tip is that (50 ms) with a space doesn't do. Leave the space out. (50ms) (replace) spaced does work though.

Share and enjoy...

---

This page edited and maintained by the Editors of Linux Gazette
HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

---