lkml.org 
[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: linux-kernel-digest V1 #4149
In <199907160352.UAA29162@bitmover.com> Larry McVoy (lm@bitmover.com) wrote:

> : But okay, let's try to implement this signal thing using an existing
> : interface and using the classical UNIX definition of processes
> : (post-clone() semantics, that's essentially identical to what's typically
> : called threads today). Well, we need something resembling a process group
> : -- for lack of better terms, I'll call it a process cluster, to indicate
> : that it's closer bound than a process group. A signal sent to a process
> : cluster gets sent to some member that doesn't have it blocked. Great!

> First of all, just use the existing process groups. While this can be
> somewhat annoying, it is perfectly capable of handling what you need for
> threads since they are all related (the only real problem with process
> groups is that unrelated processes can't join them - this is something
> I'd really like to see fixed, but's off topic here since pthread_creat()
> implies a common ancestory so the processes/threads are all related and
> a process group mechanism will work fine).

They are related, but not "related enough" ! It's exactly why LinuxThreads are
so slow :-(( `Any thread in the process can do the equivalent of waitpid for
any other thread in the process. Linux doesn't allow that; you can only wait
for a task that you yourself spawned (unless you are init). The workaround is
to make all the threads children of the "manager". It waits for them and
passes back exit statuses to the threads calling pthread_join.'

BTW talking about threads and "process clusters": Java allows you to have
hierarchy of ThreadGroups. So any thread can be member of few. IMO this can
be easily supported by clone() model if usage of process groups will be
extended so you'll be able to add process in process group and you'll be able
to have process as member of TWO (or more!) process groups. Then POSIX threads
can be emulated with easy and even more complex Java model will work without
big userspace kludges...

> : Oops, we could support process groups using negative pid parameters to
> : kill(2), but that doesn't work so well now that there are three cases.

> I don't see three cases, I just see one: a process group and sending
> signals to a process group (well, two, because you need to send signals
> to processes, but let's ignore that).

Why we can not use the same numbers for pid's and process group id's ? Then
we can use the same kill call without any modifications in interface...

> : Sound good so far? Now let's take what we're calling a process and
> : rename it to a thread. Take what we're calling a process cluster and
> : rename it to a process.

> Let's not. I think we already have all the objects that you need to do
> what you want.

If one process can become member of few "process clusters" then you just can not
call result "process" and former process "thread": it will be really confusing
to have few processes with the same threads inside !

> : a) This is all assuming you can make some assumptions about the
> : implementation of apache. In this case, work happens to be distributed
> : equally among a lot of processes. Not all thread applications are
> : symmetrical. You can use that information, of course, but only if you
> : happen to know how apache works.

> The key point here is that I can get at the information if I know what it
> means without having to reinvent ps, top, kill, strace, ltrace, etc. In
> a thread based model where the threads are hidden behind a single process,
> someone has to rewrite all of those tools. I sure don't want to do that.

It's religious question ...

: >> In general, each time some bright mind comes up with some new idea,
: >> I want that idea to be wedged into some existing interface
> :
> : Unless the existing interface is insufficient. Like it is in this case.

They are [almost] sufficient. Small modifications for kernel are needed but
most work must be done in userspace.

> Anyway, I hope that we can work together towards something that is simple,
> makes sense for all sorts of threads (threads or processes), and is
> something that Linus would like. Let me know what I can do to help.





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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