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 <Pine.LNX.3.96.990716084708.1928A-100000@walker1-46.reshall.ou.edu> cd_smith@ou.edu (cd_smith@ou.edu) wrote:
c> On Fri, 16 Jul 1999, Khimenko Victor wrote:
>> Hmm. Why to limit it this way ? Why not have arbitrary ThreadGroups so you
>> can have 10 threads in some http-database gateway to work with database,
>> 10 different threads to work with network and all under ubrealla of the same
>> process ?

c> I think that's going a little far. What do you gain from having thread
c> groups recognized by the kernel? You're obviously thinking of the Java
c> model, but Java uses them as an organizational tool that can be just as
c> easily (and cleanly) implemented in user space.

Not with signal delivery AFAIK.

c> Fact is, different processes ("process clusters") will own threads
c> (processes) that are related in a lot of different ways to each other,
C> NONE of which matter to the kernel.

Hierarchy is not realted to kernel, of course. But need ThreadGroups in kernel
for right signal delivery !

c> Not even hierarchy makes much sense when threads (processes)
c> are that closely related - but we can ignore it.

Hierarchy is not belond to kernel.

c> But introducing yet another arbitrary organization like thread
c> groups - that's messy to implement in the kernel and does no one any good
c> by being there - is working backwards.

Let's think about Apache's multi-process multi-thread mode: few processes
with few threads in each. What a gain ? Well, if there are some bugs in some
third-party Apache module then something nasty can occurs. In such case
process will be killed (and few http-connections will be dropped, of course)
but server will be alive. But then you have the same problem as now: you have
web-server not as one process but as bunch of related process'es and you can
not shutdown them easily, etc. So to have different ThreadGroups for sending
different signals can be usefull sometimes. Now in "full version" of thread
support there are two levels: process groups and process as group of thread.
Why to limit it this way ? I'm not said that it's important to have such
ability but if some new concept should be introduced ("Process clusters" or
whatever) then why not implement more generic scheme if it does not introduce
additional overhead ?




-
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.246 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site