David D.W. Downey wrote:
> OK, at the risk of sounding like an idiot let me ask the following.
Don't ask, never know.
> If application A is running (the process), the functions that comprise
> that process are the threads? Or at least if it's compiled using the
> pthreads library? If so, then what is it from compiling against that lib
> that changes the functions' attributes from that of "normal" functions
> like say ptrace() or fopen()?
No. A thread is a stream of control or execution within a program; but
all threads share the same process space. Another way of looking at it
is that there are multiple 'processes' running within the constraints
of an external Unix/Linux process.
The perceived advantage is that each thread is much more "lightweight"
than a full fork/exec or vfork of a separate process. Also, since they
share the same address space, inter-thread communication is much less
expensive, and all threads in a process share data. Threads, to many,
are more intuitive and sensible in an event-driven application, rather
than the sequential execution usual in a single "heavyweight" process.
Also, with a cooperating compiler and system, good use can be made of
multiple processors via threads.
The perceived disadvantages are that all threads in a process share
data. You have no protection from a misbehaving thread; in effect,
imagine that you're running a set of processes on a machine with no
memory management protection. This means that the author must maintain
a nice sense of critical code regions, inter-thread cooperation in use
of shared resources, etc., or things can become...interesting...to
debug.
For the nitmasters: This is simplified. As usual, there can be
threadish behavior in traditional heavyweight processes, there are some
mechanisms to mitigate shared memory issues, etc., etc.
Cheers,
--
Dave Ihnat
[EMAIL PROTECTED]
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
