Re: [rox-devel] fork()ing actions, was: Win2k port

[Thomas L. <ta...@ec...>]

On Fri, Oct 26, 2001 at 08:46:25AM +0100, Stephen Watson wrote:
> In message <004501c15de3$af90db30$0201a8c0@rowboat>
>           "Robin Rowe" <rower@MovieEditor.com> scribbled:
> 
> > Second question, what is the thinking behind this function in action.c:
> > 
> > /* Create two pipes, fork() a child and return a pointer to a GUIside struct
> >  * (NULL on failure). The child calls func().
> >  *
> >  * If autoq then automatically selects 'Quiet'.
> >  */
> > static GUIside *start_action(gpointer data, ActionChild *func, gboolean
> > autoq)
> > {    ...
> > }
> > 
> > Why is it forking here?
> 
> I guess because it is the easiest way of running the action in a seperate
> thread leaving the filer free to respond to the user.  It would be more
> efficient (if a lot more coding) to use gthreads, but even 2 copies of the
> filer don't use up much resources.

Just a couple of points about that:

- Using threads means using the thread-safe glib functions instead of the
  normal ones. These do locking, and therefore slow the whole program down
  (probably costing more time than multi-threading saves).

- The "2 copies" of the filer share all their memory until one copy
  actually changes a page; then that page (only) is copied.

Threading is only really useful when you want the threads to share memory.
Passing data by sharing memory is much faster than sending it down a pipe.
But since we're only sending text messages, it shouldn't matter
(displaying the text messages is the bottleneck).

In fact, we want to do the opposite of sharing data: when we fork, the
action window should operate on the files that *were* selected, even if we
change the selection during the operation. With threading, we'd have to
make a copy of the selected files first, but with forking the kernel only
does the copy when needed (ie, if the selection actually changes).

Not that speed is really an issue in any of this, I just provide the above
for interest's sake ;-)


-- 
Thomas Leonard			http://rox.sourceforge.net
ta...@ec...		ta...@us...