lkml.org 
[lkml]   [1999]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-kernel-digest V1 #4149

Larry McVoy writes:
> [somebody]
>> On Thu, 15 Jul 1999, Larry McVoy wrote:

>> Just for clarity, the way POSIX threads are specified right now says
>> that a signal sent to a process will be delivered to any one thread
>> in that processes that:
>>
>> a) is not blocking the signal via pthread_sigmask(), OR
>> b) is waiting on that signal with sigwait()
>>
>> If no thread meets any of the above circumstances, then the signal will
>> remain pending at the process level until any thread does meet one of the
>> above, at which time it will be delivered. Which thread receives the
>> signal is not specified, but it will only be one thread. The signal is
>> NOT delivered to all threads at once.
>
> You're right. Point conceeded, but it then raises another point. This is
> a different, you can argue whether it is useful or not, semantic for
> signals, along with a different set of interfaces for manipulating them.

Yep. It is Standard. If you want to forget POSIX, just say so. I'd like to
meet the standard, but if we don't... might as well kill some other POSIX
junk as well. Being almost-POSIX isn't worth much.

> My point is that there should be exactly one kind of process primitive.
> I could care less if you call it a thread, a process, a task, or
> a foobar. There shouldn't be two or three or four different ones any

Go bitch to the IEEE.

>> No, the right answer is to not get stuck in the past. Except to someone
>> that has been around UNIX before threads were there, the fact that there
>> are five instances of apache running on the same system looks mighty
>> strange. All five "processes" are doing the same thing, and it is only a
>> relic of the past that we show apache five times. In other words, USING
>> PROCESSES FOR CONCURRENCY IS A KLUDGE.
>
> Can't agree.

This should be obvious, but: threads, signals, and the use of multiple
processes are all kludges. Die, die die!!! :-) Blocking system calls
are crap, and interruptible calls are extreme crap. It is better to
go with something a bit more like SCSI. One could fire off system calls
in groups, finish some useful work, then wait for completion of any
system calls whose results are needed.

> I really like that I can do a ps axu | grep http and see
> nobody 23937 0.0 3.5 3152 2268 ? S 08:24 0:00 httpd
> nobody 23939 0.0 3.5 3152 2264 ? S 08:24 0:00 httpd
> nobody 25502 0.0 3.5 3152 2260 ? S 12:11 0:00 httpd
> nobody 25946 0.0 3.5 3152 2260 ? S 13:14 0:00 httpd
> nobody 25950 0.0 3.5 3140 2260 ? S 13:14 0:00 httpd
> nobody 26079 0.0 3.5 3140 2256 ? S 13:36 0:00 httpd
> nobody 26089 0.0 3.5 3152 2260 ? S 13:38 0:00 httpd
> nobody 26093 0.0 3.5 3140 2256 ? S 13:38 0:00 httpd
> nobody 26094 0.0 3.6 3212 2324 ? S 13:38 0:00 httpd

That will die (assuming those are supposed to be threads) as soon
as I figure out how to get a unique VM ID from userspace and find
the time to fix ps.

Every system I know with real threads (AIX, Digital UNIX, SunOS, UnixWare)
provides an option to list threads separately, so I don't see your point.
You should be familiar with Sun's "-L" option.

> That tells me something. In this case, it sort of suggests that I don't
> need more than 6 of 'em, 2 of them aren't getting used very much.
>
> In general, each time some bright mind comes up with some new idea,
> I want that idea to be wedged into some existing interface - be it a

Let's all pound big square pegs into little round holes.

>> If I'm running apache, all I want to know is that I have a web browser
>> running. Since neither I nor my other processes on the system understand
>> exactly how apache is dividing its workload between five forked copies,
>> neither I nor my other processes need to see apache as anything but a
>> single entity, the web browser. Doing otherwise is akin to letting one
>> process muck around in another's unrelated process's address space. It's
>> a clearly bad idea.
>
> Hmm. So is letting one thread muck about in another thread's address space
> a bad idea also? Clearly not.

Clearly yes. The system must meet normal expectations.

> So you want to decide for me whether or not
> I can view threads individually or not. With all due respect, no thanks.
> If you want to not see 8 http processes, I'll happily write you a version of
> ps which finds all of them, adds up their resource usage, and reports them

Please do, or at least tell me how. (the signal ID is not quite right)

> as one entity. I can do that and satisfy your needs. However, you can
> not satisy mine with your model - if I want to see what each thread is doing,
> I can't use top/ps/strace/ltrace or any of the other process oriented tools.

ps -efL
ps auxm

> ALL of those have to be rewritten.

Well, updated at least. The kernel and libc needed updates too.
Your point?

> And without OS support, some of them
> can not be rewritten. Once again showing you that the process model can
> emulate the threaded model but not the other way around.

Huh? Without OS support, you don't have clone() or threads at all.
All of this stuff needs OS support, libc support, and system software
support.

I'd love to add support for /proc files like Solaris has, but we have
some fundamental incompatibilities AFAIK and /proc/*/status is taken.

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