Re: Event loop

["Earle R. Nietzel" <nietzel yahoo com>]

Agreed there is a smaller difference on a Linux machine than others but lets
just hit the basics of a process and a thread.

All threads in a process share the same address space (code data), stack,
file descriptors, everything.

( Context Switches )
When a processor switches between processes all of the hardware state for
that process becomes invalid we're talking about during a context switch
procedure - data cache and virtual memory translation entries may be flushed
or is no longer valid to the current process.

Finally Synchroniztion is a lot FASTER, you don't need to use shared memory
or pipes. Threads make better use of high bandwith memory synchronization
techniques.

These are just the basics as to why threads are faster. A thread is really
just a trimmed down process that has access to all of your programs
resources.

It really doesn't matter so much that a process or thread get created by the
same mechanism clone(), because they really are similar but there are major
differences between them which brings us back to DESIGN...

If you need further information read "Programming with POSIX Threads" -
Butenhof 1997

Just some more info for the interested...

Earle

> On 11 Nov, Earle R. Nietzel wrote:
> > I think you mean threads not another process...
> >
> > Threads are a much better solution than creating another process...
>
> Depends on the OS, the application, and the threading library you use,
> IMHO.
>
> On Linux the difference between threads and processes isn't very big.
AFAIK
> a thread uses the same memory-page for it's data as it's parent, while a
> process does not. Both are created with clone(2), so I'd think there's no
> big difference in overhead between creating a thread and a process.
>
> Besides, access to the parent's memory can be a mixed blessing. Especially
> if the app gets bigger, and you forget to lock a variable with a
semaphore.
> If you divide your app into separate processes, you can test and debug the
> background (work) process seperately. There is some overhead, as you must
> define the communication means and messages between the processes, using
> files, message queues or whatever. But you don't have to worry about
> different threads overwriting the same variable.
>
> If you use a threading library that is contained within a single process,
> it will make your GTK+ interface less responsive, if it's doing heavy
> processes.
>
> Besides, once you've written some helper functions, using and
communicating
> with different child processes isn't that hard. My own implementation is
> under a thousand lines of C code. If anybody is interested, I'll place it
> on my web page.
>
> Just my $0.02
>
> Roland
> --
> Roland Smith                        "When life hands you a lemon,
> r s m i t h @ x s 4 a l l . n l      make lemonade."
> http://www.xs4all.nl/~rsmith/
>
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com