[lkml]   [1996]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: LWPs (was:Re: proc fs and shared pids)
From wrote:
> Hi,
> It's been a few years since I looked (and messed) around with
> threads, so forgive any errors I make. The below is given as
> food for thought...
> As I remember, there are 3 basic types of threads;
> o Kernel Thread (basically for _kernel_ processes)
> o Light Weight Process (what I'm interrested in here)
> o User Level Thread
> clone() tries to give Linux LWPs. Basically, this involves
> allocating and setting up a _new_ task struct, and referencing some
> other structures (signal handlers, etc) from the clone()ing process. I
> would say this is the _wrong_ way round.
> The new thread should use the _old_ task struct, and allocate memory
> for the state which it does not want to share with the cloning process.
> This could be achieved with a new structure 'thread struct', which
> contains the thread's state. An incomplete list of what would be in the
> thread struct;

[ ... ]

> Under '/proc/pid' would be the 'normaly' files that contain the
> task info, and a sub-directory for each thread in the task.
> OK, I've missed a lot out, but this is the basic idea.
> Comments?
> markhe

This sounds exactly like processes and process groups, with the added
kink that the processes can share memory.

Let me give an example for my case. Suppose I want to write an X program
which does some lengthy computation, and I decide to have one thread
do the calculation while a second thread draws intermediate results in
a window. Here are two options I have under Linux 2.0:

1) Use clone() to create the threads, and communicate via
shared memory.

2) Use fork() to create the "threads", and communicate via

From the kernel's perspective these two have some significant
differences, but from the perspective of userspace each just looks a
pair of cooperating processes. In neither case would you want to throw
a signal to just one of the two "threads"; you should send it to both
of them and let them divvie it up however seems reasonable.

I guess basically what I'm saying is, if we just rename the term "process
ID" to "thread ID", don't we have already the functionality we want,
without confusing old software that doesn't know about threads.

Hmm, just came to mind: in any case, allowing multiple processes sharing
the same pid is not currently fully functional (note the sebject of the
thread!); shouldn't this option be dissalowed until 2.1?


 \ /
  Last update: 2005-03-22 13:37    [W:0.060 / U:1.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site