Re: Alan Cox quote? (was: Re: accounting for threads)

Re: Alan Cox quote? (was: Re: accounting for threads)

[Joerg Pommnitz]

 > But that foregoes the point that the code is far more complex and
 > harder to make 'obviously correct', a concept that *does* translate
 > well to userspace.

Check the state threads library from SGI:
http://oss.sgi.com/projects/state-threads/

It should provide the code clarity one is used from
"real" threads and the efficiency of a state machine.

Regards
  Joerg



=====
-- 
Regards
       Joerg


__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On Tue, 19 Jun 2001, Joerg Pommnitz wrote:

>  > But that foregoes the point that the code is far more complex and
>  > harder to make 'obviously correct', a concept that *does* translate
>  > well to userspace.
> 
> Check the state threads library from SGI:
> http://oss.sgi.com/projects/state-threads/
> 
> It should provide the code clarity one is used from
> "real" threads and the efficiency of a state machine.

... along with usual quality of SGI design and their normal attention
to potential races. Thank you, I'll pass.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jan Hudec]

Hello,

> I am happy that processes in Linux are so marvelous. Linux does not need
> a decent POSIX threads implementation because the same functionality can
> be achived with processes. Do what you like, you write the kernel code.
> I could write my soft using fork special fetaures in Linux.
> But I want it to be portable. If threads in linux are so bad, it is bad
> luck for me. I will go slow. It its the only portable way todo afordable
> shared memory threading without filling your program of shm-xxxx.

AFAIK, there is a POSIX thread library (libpthread) for Linux, that wraps
clone calls in a way portable to other unices. It uses processes (with memory
sharing) from kernel point of view, but should look like POSIX threads from
application point of view.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Re: Alan Cox quote? (was: Re: accounting for threads)

[J . A . Magallon]

This discussion seems to go nowhere. Thanks for your comments. I know much
more on Linux than before.

I am happy that processes in Linux are so marvelous. Linux does not need
a decent POSIX threads implementation because the same functionality can
be achived with processes. Do what you like, you write the kernel code.
I could write my soft using fork special fetaures in Linux.
But I want it to be portable. If threads in linux are so bad, it is bad
luck for me. I will go slow. It its the only portable way todo afordable
shared memory threading without filling your program of shm-xxxx.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686

Re: Alan Cox quote? (was: Re: accounting for threads)

[Galen Hancock]

On Mon, Jun 25, 2001 at 12:30:02AM +0200, J . A . Magallon wrote:
> shell scripting, for example. Or multithreaded web servers. With the above
> test (fork() + immediate exec()), you just try to mesaure the speed of fork().

The benchmark that used lmbench that was posted tested fork follwed fork
by exit not follwed by exec.

Although you could have used vfork in that test, the point of the test
was to get some feel for how much overhead the fork and exit together
had. A real application could not use vfork, because it would do some
actual work before the exit.

> Say you have a fork'ing server. On each connection you fork and exec the
> real transfer program.

Most forking servers I know of don't exec programs to deal with accepted
connections. (The only exception I can think of is inetd and its
cousins, the performance of which is not important.)

>                        There time for fork matters. It can run very fast
> in Linux but suck in other systems. Just because the programmer chose fork()
> instead of vfork().

vfork is not portable. There are standards that specify what it does,
but the portable semantics are so useless that if you use it you will
almost certainly wind up with undefined behavior.

However, the original discussion was about threads. How to do fork+exec
(or vfork+exec if you insist on using that broken interface) quickly is
beside the point.

> >> The clean battle should be linux fork-exec vs vfork-exec in
> >> Solaris, because for in linux is really a vfork in solaris.

> >But the point of threading is it's a fork WITHOUT an exec.

> Not always, see above.

You appear to be saying that spawning child programs is an example of
threading. I don't think that's what most people mean by threading.

					Galen

Re: Alan Cox quote? (was: Re: accounting for threads)

[Davide Libenzi]

On 25-Jun-2001 Gerhard Mack wrote:
>> BTW, after all I have read all POSIX threads library should be no more than
>> a wrapper over fork(), clone and so on. Why are they so bad then ?
>> I am going to get glibc source to see what is inside pthread_create...
> 
> If I recall it had to do with problems in signal delivery...

1) pthread_create() does not create the thread, it write through a pipe to a
        thread manager that will create a thread

2) pthread ( in linux ) is signal intensive




- Davide

Re: Alan Cox quote? (was: Re: accounting for threads)

[Gerhard Mack]

> BTW, after all I have read all POSIX threads library should be no more than
> a wrapper over fork(), clone and so on. Why are they so bad then ?
> I am going to get glibc source to see what is inside pthread_create...

If I recall it had to do with problems in signal delivery...



--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: Alan Cox quote? (was: Re: accounting for threads)

[J . A . Magallon]

On 20010625 Larry McVoy wrote:
>
>One for the quotes page, eh?  We're terribly sorry, we'll get busy on adding
>some delay loops in Linux so it too can be slow.
>-- 

I was afraid someone would tell that...

I just want to say that the 'problem' is not that threads are slow in linux,
but that others ways are faster than they 'should be if done the standard
way'.

BTW, after all I have read all POSIX threads library should be no more than
a wrapper over fork(), clone and so on. Why are they so bad then ?
I am going to get glibc source to see what is inside pthread_create...

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Mon, Jun 25, 2001 at 12:30:02AM +0200, J . A . Magallon wrote:
> They use fork().
> They port their app to solaris.
> The performance sucks.
> It is not Solaris fault.
> It is linux fast fork() ...

One for the quotes page, eh?  We're terribly sorry, we'll get busy on adding
some delay loops in Linux so it too can be slow.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Steven Walter]

On Mon, Jun 25, 2001 at 12:30:02AM +0200, J . A . Magallon wrote:
> Take a programmer comming from other system to linux. If he wants multi-
> threading and protable code, he will choose pthreads. And you say to him:
> do it with 'clone', it is better. Answer: non protable. Again: do it
> with fork(), it is fast in linux. Answer: better for linux, but it is a
> real pain in other systems.
> 
> And worst, you are allowing people to program based on a tool that will give
> VERY diferent performance when ported to other systems. They use fork().
> They port their app to solaris. The performance sucks. It is not Solaris
> fault. It is linux fast fork() that makes people not looking for the
> correct standard tool for what they want todo.

This sounds to my like "Linux is making other OSes look bad.  Cut it
out."
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell

Re: Alan Cox quote? (was: Re: accounting for threads)

[J . A . Magallon]

On 20010624 Rob Landley wrote:
>
>This is a bit like like saying that a truck and a train are totally different 
>beasts.  If I'm trying to haul cargo from point A to point B, which is served 
>by both, all I care about is how long it takes and how much it costs.
>
>I don't care what it was INTENDED to do.  A rock makes a decent hammer.  So 
>does a crescent wrench.  The question is how good a tool is it for the uses 
>we're trying to put it to?
>

Well, the problem is that when somebody says you it has a truck to take your
cargo, you have your idea of a truck, and there is a standard idea of
the difference between a train and a truck.

Tools have been developed for multi-processing in unix, processes and threads.
And have a difference. And when you design your algorithm (and more if you
want it to be protable), you think if you want it done with processes or
you need threads (posix, or lwps or whatever). And you decide it on the
standard idea of what a process and a thread are.

Take a programmer comming from other system to linux. If he wants multi-
threading and protable code, he will choose pthreads. And you say to him:
do it with 'clone', it is better. Answer: non protable. Again: do it
with fork(), it is fast in linux. Answer: better for linux, but it is a
real pain in other systems.

And worst, you are allowing people to program based on a tool that will give
VERY diferent performance when ported to other systems. They use fork().
They port their app to solaris. The performance sucks. It is not Solaris
fault. It is linux fast fork() that makes people not looking for the
correct standard tool for what they want todo.

Instead of trying to enhance linux thread support, you try to move programmes
to use linux 'specialities'.

>> This remembers on other question I read in this thread (I tried to answer
>> then but I had broke balsa...). Somebody posted some benchmarks of linux
>> fork()+exec() vs Solaris fork()+exec().
>
>What programs does this make a difference in?  These are tools meant to be 
>used.  What real-world usage causes them to differ?  If a reasonably 
>competent programmer ported a program from one platform to another, is this 
>the behavior they would expect to see (without a major rewrite of the code)?
>
>> That is comparing apples and oranges.
>
>Show me a real-world program that makes the distinction you're making.  
>Something in actual use.
>

shell scripting, for example. Or multithreaded web servers. With the above
test (fork() + immediate exec()), you just try to mesaure the speed of fork().
Say you have a fork'ing server. On each connection you fork and exec the
real transfer program. There time for fork matters. It can run very fast
in Linux but suck in other systems. Just because the programmer chose fork()
instead of vfork().

>> The clean battle should be linux fork-exec vs vfork-exec in
>> Solaris, because for in linux is really a vfork in solaris.
>
>But the point of threading is it's a fork WITHOUT an exec.
>

Not always, see above.

>
>I'm not going to comment on the difference between fork and vfork becaue to 
>be honest I've forgotten what the difference is.  Something to do with 

Time.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686

Re: Alan Cox quote? (was: Re: accounting for threads)

[J . A . Magallon]

On 20010622 Rob Landley wrote:
>
>I still consider the difference between threads and processes with shared 
>resources (memory, fds, etc) to be largely semantic.
>

They should not be the same. Processes are processes, and threads were designed
for situations where processes are too heavy. Other thing is that in new
kernels (for example, Linux) processes are being optimized (ie, vm fast
'cloning' via copy-on-write) or expanded with new features (Linux' clone+
CLONE_VM). But they are different beasts.

This remembers on other question I read in this thread (I tried to answer then
but I had broke balsa...). Somebody posted some benchmarks of linux
fork()+exec() vs Solaris fork()+exec(). That is comparing apples and
oranges. The clean battle should be linux fork-exec vs vfork-exec in Solaris,
because for in linux is really a vfork in solaris.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Sunday 24 June 2001 19:50, Larry McVoy wrote:
> On Mon, Jun 25, 2001 at 12:30:02AM +0200, J . A . Magallon wrote:
> > They use fork().
> > They port their app to solaris.
> > The performance sucks.
> > It is not Solaris fault.
> > It is linux fast fork() ...
>
> One for the quotes page, eh?  We're terribly sorry, we'll get busy on
> adding some delay loops in Linux so it too can be slow.

I'm still working that one out myself...

Okay, so Linux programmers are supposed to avoid APIs that are either 
broken, badly implemented, or missing, on some other platform.

That's pretty much all of them, isn't it?

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Sunday 24 June 2001 18:30, J . A . Magallon wrote:

> Take a programmer comming from other system to linux. If he wants multi-
> threading and protable code, he will choose pthreads. And you say to him:
> do it with 'clone', it is better. Answer: non protable. Again: do it
> with fork(), it is fast in linux. Answer: better for linux, but it is a
> real pain in other systems.

So we should be as bad as other systems?  I'm trying to figure out what 
you're saying here...

> And worst, you are allowing people to program based on a tool that will
> give VERY diferent performance when ported to other systems. They use
> fork(). They port their app to solaris. The performance sucks. It is not
> Solaris fault. It is linux fast fork() that makes people not looking for
> the correct standard tool for what they want todo.

Hang on, the fact the LInux implementation of something is 10x faster than 
somebody else's brain damaged implementation is Linux's fault?

On Linux, there is no real difference between threads and processes.  On some 
other systems, there is unnecessary overhead for processes.  "Threads" are 
from a programming perspective multiple points of execution that share an 
awful lot of state.  Which basically, processes can be if you tell them to 
share this state.

>From a system perspective threads are a hack to avoid a lot of the overhead 
processes have poisoning caches and setting up and tearing down page tables 
and such.  Linux processes don't have this level of overhead.

So -ON LINUX- there isn't much difference between threads and processes.  
Because the process overhead threads try to avoid has been optimized away, 
and thus there is a real world implementation of the two concepts which 
behaves in an extremely similar manner.  Thus the conceptual difference 
between the two is mostly either artificial or irrelevant, certainly in this 
context.  If there is a context without this difference, then in other 
contexts it would appear to be an artifact of implementation.

On Solaris there is a difference between threads and processes, but the 
reason is that Solaris' processes are inefficient (and shown by the 
benchmarks you don't seem to like).

> Instead of trying to enhance linux thread support, you try to move
> programmes to use linux 'specialities'.

No, I'm saying Linux processes right now have 90% of the features of thread 
support as is, and the remaining differences are mostly semantic.  It would 
be fairly easy to take an API like the OS/2 threading model and put it on 
Linux.  From what I remember of the OS/2 threading model, we're talking about 
a couple hours worth of work.

Adding support for the Posix model is harder, but from what I've seen of the 
Posix model this is because it's evil and requires a lot of things that don't 
really have much to do with the concept of threading.

I will admit that Linux (or the traditional unix programming model) has some 
things that don't mesh well with the abstract thread programming model.  
Signals, for example.  But since the traditional abstract threads model 
doesn't try to handle signals at ALL that I am aware of (OS/2 didn't, Dunno 
about NT.  Posix has some strange duct-tape solution I'm not entirely 
familiar with...  In java you can kill or suspend a thread which is 
IMPLEMENTED with signals but conceptually discrete...)

> >> That is comparing apples and oranges.
> >
> >Show me a real-world program that makes the distinction you're making.
> >Something in actual use.
>
> shell scripting, for example.

You've done multi-threaded shell scripting?  I tried to use bash with 
multiple processes and ran into the fact that $$ always gives the root 
process's PID, and nobody had ever apparently decided that this was dumb 
behavior...

> Or multithreaded web servers.

Apache has a thread pool, you know.  Keeps the suckers around...

> With the above
> test (fork() + immediate exec()), you just try to mesaure the speed of
> fork(). Say you have a fork'ing server. On each connection you fork and
> exec the real transfer program.

Like a CGI script, you mean?  Not using mod_perl or mode_php but shelling out?

And you're worried about performance?

> There time for fork matters. It can run
> very fast in Linux but suck in other systems.

And this is linux's problem, is it?

> Just because the programmer
> chose fork() instead of vfork().

So "#define fork vfork" would not be part of the "#ifdef slowaris" block then?

I'm still a bit unclear about what the behavior differences of them actualy 
are.  I believe vfork is the hack that goes really funny if you DON'T exec 
immediately after calling it.  Yet the argument here was about THREADS, which 
don't DO that.  So the entire discussion is a red herring.  If you're going 
to fork and then exec, you're not having multiple points of execution in the 
same program.

Linux can do this efficiently on a process level because its fork is 
efficient (and it has clone() which allows more control over what gets shared 
between processes.)  Solaris makes an artificial distinction between 
processes and threads because A) its fork implementation sucks, B) it doesn't 
allow granualr control over what gets shared between processes.

How does any of this point to a deficiency in Linux rather than Solaris?  
(Don't give me "standards", there's an official standard for EBCDIC.)

> >> The clean battle should be linux fork-exec vs vfork-exec in
> >> Solaris, because for in linux is really a vfork in solaris.
> >
> >But the point of threading is it's a fork WITHOUT an exec.
>
> Not always, see above.

Does "vfork" without "exec" work reliably?  Anybody wanna clear this up?

> >I'm not going to comment on the difference between fork and vfork becaue
> > to be honest I've forgotten what the difference is.  Something to do with
>
> Time.

You are clearly oversimplifying or else "fork" wouldn't exist.  Even Sun 
isn't going to put in an intentionally slower API that's otherwise 
functionally identical to another API.  If nothing else they'd implement one 
as a wrapper that calls the other with the arguments converted.

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Sunday 24 June 2001 17:41, J . A . Magallon wrote:
> On 20010622 Rob Landley wrote:
> >I still consider the difference between threads and processes with shared
> >resources (memory, fds, etc) to be largely semantic.
>
> They should not be the same. Processes are processes, and threads were
> designed for situations where processes are too heavy. Other thing is that
> in new kernels (for example, Linux) processes are being optimized (ie, vm
> fast 'cloning' via copy-on-write) or expanded with new features (Linux'
> clone+ CLONE_VM). But they are different beasts.

This is a bit like like saying that a truck and a train are totally different 
beasts.  If I'm trying to haul cargo from point A to point B, which is served 
by both, all I care about is how long it takes and how much it costs.

I don't care what it was INTENDED to do.  A rock makes a decent hammer.  So 
does a crescent wrench.  The question is how good a tool is it for the uses 
we're trying to put it to?

> This remembers on other question I read in this thread (I tried to answer
> then but I had broke balsa...). Somebody posted some benchmarks of linux
> fork()+exec() vs Solaris fork()+exec().

What programs does this make a difference in?  These are tools meant to be 
used.  What real-world usage causes them to differ?  If a reasonably 
competent programmer ported a program from one platform to another, is this 
the behavior they would expect to see (without a major rewrite of the code)?

> That is comparing apples and oranges.

Show me a real-world program that makes the distinction you're making.  
Something in actual use.

> The clean battle should be linux fork-exec vs vfork-exec in
> Solaris, because for in linux is really a vfork in solaris.

But the point of threading is it's a fork WITHOUT an exec.

So now you're saying the comparison we're making of "using these tools to do 
goal X" is invalid because you don't like goal X, and you want to do 
something else with them.

I'm not going to comment on the difference between fork and vfork becaue to 
be honest I've forgotten what the difference is.  Something to do with 
resource sharing but darned if I can remember it.  I'm not sure I've ever 
used vfork, last thing I remember were people arguing over the man page for 
it...

(Sorry  if I seem a bit snappish, I've had this kind of discussion too many 
times with ivory tower types at UT who object to the topic of conversation 
because it's not what they've focused on until now.  Which logical fallacy 
was this, "begging the question"?  Straw man?  I forget.  I'm tired...)

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Richard Gooch]

Alexander Viro writes:
> BTW, proc_net_create() is also not a good idea if you block the
> interrupts.  Ditto for netlink_kernel_create(), AFAICS (due to
> netlink_kernel_creat() -> sock_alloc() -> get_empty_inode() ->
> kmem_cache_alloc() with SLAB_KERNEL).
> 
> That, BTW, is a nice illustration - it's easy to get a preemption
> point without noticing, so holding spinlocks, let alone disabling
> interrupts over the large area is going to hurt like hell.

Here's an idea: add a CONFIGable debug mode for spinlock/cli
interaction with GFP_KERNEL and other (known) blocking operations.
Keep a per-CPU flag or bitmask that's manipulated by lock/cli
operations and checked by memory allocators and other key blocking
operations. Generate an Oops upon violation.

Make the CONFIG option initially set to 'y' for a patch level or two.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mikulas Patocka]

> > A lot of OS/2 software is written with this feature in mind.  I know of one
> > programmer who absolutely hates Linux because it's just too difficult
> > porting software to it, and the lack of decent thread support is part of
> > the problem.
> 
> Yup.  OS/2 is the largest nest of trained, experienced multi-threaded 
> programmers.  (And it takes a LOT of training experience to do threads 
> right.)  That's why I've been trying to recruit ex-OS/2 guys over to Linux 
> for years now.  (Most followed Java to Linux after Netscape opened up 
> Mozilla, but there used to be several notable holdouts...)

I did some threaded programming on OS/2 and it was real pain. The main
design flaw in OS/2 API is that thread can be blocked only on one
condition. There is no way thread can wait for more events. For example I
have a thread that processes GUI messages. It is blocked in WinGetMsg -
waiting for messages from pmshell. Now another part of application needs
to wake up the thread to do some things - but there is no way to wake it
up because the thread can't wait for anything else than messages from
pmshell. I actually had to create dummy invisible window. I send messages
to that GUI thread via event queue of that window - really dirty but it
can't be done otherwise. 

When OS/2 designers realised this API braindamage, they somewhere randomly
added funtions to unblock threads waiting for variuos events - for example
VioModeUndo or VioSavRedrawUndo - quite insane.

Programming with select, poll and kqueue on Unix is really much better
than with threads on OS/2. 

Mikulas

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Friday 22 June 2001 10:46, Mikulas Patocka wrote:

> I did some threaded programming on OS/2 and it was real pain. The main
> design flaw in OS/2 API is that thread can be blocked only on one
> condition. There is no way thread can wait for more events. For example 

Sure.  But you know what a race condition is, and how to spot one (in 
potential during coding, or during debugging.)  You know how to use 
semaphores and when and why, and when you DON'T need them.  You know about 
the potential for deadlocks.

And most of all, you know just because you got it to run once doesn't mean 
it's RIGHT...

> When OS/2 designers realised this API braindamage, they somewhere randomly
> added funtions to unblock threads waiting for variuos events - for example
> VioModeUndo or VioSavRedrawUndo - quite insane.

OS/2 had a whole raft of problems.  The fact half the system calls weren't 
available if you didn't boot the GUI was my personal favorite annoyance.

It was a system created _for_ users instead of _by_ users.  Think of the 
great successes in the computing world: C, Unix, the internet, the web.  All 
of them were developed by people who were just trying to use them, as the 
tools they used which they modified and extended in response to their needs.

This is why C is a better language than pascal, why the internet beat 
compuserve, and why Unix was better than OS/2.  Third parties writing code 
"for" somebody else (to sell, as a teaching tool, etc) either leave important 
stuff out or add in stuff people don't want (featuritis).  It's the nature of 
the beast: design may be clever in spurts but evolution never sleeps.  
(Anybody who doesn't believe that has never studied antibiotic resistant 
bacteria, or had to deal with cockroaches.)

> Programming with select, poll and kqueue on Unix is really much better
> than with threads on OS/2.

I still consider the difference between threads and processes with shared 
resources (memory, fds, etc) to be largely semantic.

> Mikulas

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Andi Kleen]

Alexander Viro <viro@math.psu.edu> writes:

> On Thu, 21 Jun 2001, Rusty Russell wrote:
> 
> > Disagree.  A significant percentage of the netfilter bugs have been
> > SMP only (the whole thing is non-reentrant on UP).
> 
> I really doubt it. <looking through the thing> <raised brows>
> Well, if you use GFP_ATOMIC for everything... grep...
> Erm... AFAICS, you call create_chain() with interrupts disabled
> (under write_lock_irq_save()). Unless I'm _very_ mistaken,
> kmalloc(..., GFP_KERNEL) is a Bad Thing(tm) in that situation.
> And create_chain() leads to it.

That's the old ipchains code; if it's buggy it's likely buggy in 2.2 
too. In fact 2.2 ip_fw.c has exactly the same problem (and also a panic
on OOM) 

iptables is supposed to be somewhat better (that's the new code), with
cleaner locking.

-Andi, wondering why the Stanford Checker didn't catch that.

P.S.: Could you please always change the subject in future when going
from slashdot niveau material to real kernel bugs on l-k. thanks.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Chester Lott]

Rok papez <rok.papez@kiss.uni-lj.si> wrote:
>On Tuesday 19 June 2001 18:09, Larry McVoy wrote:
>> "If you think you need threads then your processes are too fat"
>> ``Think of it this way: threads are like salt, not like pasta You
>> like salt, I like salt, we all like salt. But we eat more pasta.''

> Here are more from the same basket you obviously got the first 
> quote from:
[SNIP]
> Protected memory is a constant 10% CPU hog needed only by
undisciplined
> programmers who can't keep their memory writes in their own process
space.

Now that's the primary reason to avoid threads, IMO.  People
spent years trying to get protected memory; the only real
difference between threads and processes is that you throw
protected memory out the window.  Yes, the pthread API sucks;
yes, there are times when threads are appropriate.

If only:
1) Microsoft, Sun, and others didn't have such abysmal
context switch numbers that people view threads vs. 
processes as a performance argument;
2) MS didn't conflate fork() and exec() into one 
CreateProcess() call; and
3) Java and others exposed rational event-driven APIs that
didn't require multiple contexts of execution in weird places
(1.4 is finally fixing this one anyway)

then people might be able to really see that:
1) You usually don't need that many contexts of execution; and
2) Processes should be considered the primary COEs and threads
only used when you really need to share almost all of your
memory.

That's aside from all the arguments against multithreading
just based on elegance and code correctness POVs.  Even if
writing multithreaded code is marginally easier than writing
poll()-based code, actually debugging it is a royal PITA.
Coroutines (which aren't Alan's, Knuth had them long before
Alan and even he was just rehashing old news) and state
machines really are better in many cases.

About the only criticism I have of Alan's statement that
"threads are for people who can't program state machines" is
the implication that threads are an easier API to get right.
They aren't.  They seem that way, but by tossing protected
memory and introducing multiple COEs you get into a whole
world of non-obvious problems that are very difficult to
debug and often nearly impossible to reproduce in 
non-production environments.

The salt quote I like; it allows for the sparing use of
threads, but warns against their over(ab)use.

Ah, well.

  Sumner

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: Alan Cox quote? (was: Re: accounting for threads)

[Michael Rothwell]

On 20 Jun 2001 10:14:48 +0100, Alan Cox wrote:

> It does. 

... not

> They are always readable.

That's not very useful. Not in the sense of supporting aync,
non-blocking i/o to disk files without using threads.


--
Michael Rothwell
rothwell@holly-springs.nc.us

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On Thu, 21 Jun 2001, Alexander Viro wrote:

> 
> 
> On Thu, 21 Jun 2001, Rusty Russell wrote:
> 
> > Disagree.  A significant percentage of the netfilter bugs have been
> > SMP only (the whole thing is non-reentrant on UP).
> 
> I really doubt it. <looking through the thing> <raised brows>
> Well, if you use GFP_ATOMIC for everything... grep...
> Erm... AFAICS, you call create_chain() with interrupts disabled
> (under write_lock_irq_save()). Unless I'm _very_ mistaken,
> kmalloc(..., GFP_KERNEL) is a Bad Thing(tm) in that situation.
> And create_chain() leads to it.

BTW, proc_net_create() is also not a good idea if you block the interrupts.
Ditto for netlink_kernel_create(), AFAICS (due to netlink_kernel_creat() ->
sock_alloc() -> get_empty_inode() -> kmem_cache_alloc() with SLAB_KERNEL).

That, BTW, is a nice illustration - it's easy to get a preemption point
without noticing, so holding spinlocks, let alone disabling interrupts
over the large area is going to hurt like hell.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On Thu, 21 Jun 2001, Rusty Russell wrote:

> Disagree.  A significant percentage of the netfilter bugs have been
> SMP only (the whole thing is non-reentrant on UP).

I really doubt it. <looking through the thing> <raised brows>
Well, if you use GFP_ATOMIC for everything... grep...
Erm... AFAICS, you call create_chain() with interrupts disabled
(under write_lock_irq_save()). Unless I'm _very_ mistaken,
kmalloc(..., GFP_KERNEL) is a Bad Thing(tm) in that situation.
And create_chain() leads to it.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Thursday 21 June 2001 10:02, Jesse Pollard wrote:
> Rob Landley <landley@webofficenow.com>:
> > On Wednesday 20 June 2001 17:20, Albert D. Cahalan wrote:
> > > Rob Landley writes:
> > > > My only real gripe with Linux's threads right now [...] is
> > > > that ps and top and such aren't thread aware and don't group them
> > > > right.
> > > >
> > > > I'm told they added some kind of "threadgroup" field to processes
> > > > that allows top and ps and such to get the display right.  I haven't
> > > > noticed any upgrades, and haven't had time to go hunting myself.
> > >
> > > There was a "threadgroup" added just before the 2.4 release.
> > > Linus said he'd remove it if he didn't get comments on how
> > > useful it was, examples of usage, etc. So I figured I'd look at
> > > the code that weekend, but the patch was removed before then!
> >
> > Can we give him feedback now, asking him to put it back?
> >
> > > Submit patches to me, under the LGPL please. The FSF isn't likely
> > > to care. What, did you think this was the GNU system or something?
> >
> > I've stopped even TRYING to patch bash.  try a for loop calling "echo
> > $$&", eery single process bash forks off has the PARENT'S value for $$,
> > which is REALLY annoying if you spend an afternoon writing code not
> > knowing that and then wonder why the various process's temp file sare
> > stomping each other...
>
> Actually - you have an error there. $$ gets evaluated during the parse, not
> during execution of the subprocess.

Well, that would explain it then.  (So $$ isn't actually an environment 
variable, it just looks like one?  I had my threads calling a seperate 
function...)

> To get what you are describing it is
> necessary to "sh -c 'echo $$'" to force the delay of evaluation.

Except that this spawns a new child and gives me the PID of the child, which 
lives for maybe a tenth of a second...

Maybe I could do something with eval...?

Either way, I switched the project in question to python.

> That depends on what you are trying to do.

A couple people emailed me and pointed out I had to set IFS=$'\n', (often 
after first saying "there's no way to do that" and then correcting themselves 
towards the end of the message...)

My first attempt to do it was to pipe the data into a sub-function do read a 
line at a time and store the results in an array.  (Seemed pretty 
straightforward.)

Except there's no way to get that array back out of the function, and that IS 
documented at the end of the bash man page.

As I said: Python.

> Are you trying to echo the
> entire "ls -l"? or are you trying to convert an "ls -l" into a single
> column based on a field extracted from "ls -l".

I was trying to convert the lines into an array I could then iterate through.

> If the fields don't matter, but you want each line processed in the
> loop do:
>
> ls -l | while read i
> do
>    echo line:$i
> done

Hmmm...  If that avoids the need to export the array from one shell instance 
to another, maybe it'd work.  (I'm not really doing echo, I was doing 
var[$i]="line", with some other misc stuff.)

But I got it to work via IFS, and that's good enough for right now.

> If you want such elaborate handling of strings, I suggest using perl.

I came to the same conclusion, but would like for more than one person to be 
able to work on the same piece of code, so it's python.  (Or PHP if Carl's 
the one who gets around to porting it first. :)  But in the meantime, the 
shell script is now working.  Thanks everybody...)

Back to talking about the kernel.:)

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jesse Pollard]

Rob Landley <landley@webofficenow.com>:
> 
> On Wednesday 20 June 2001 17:20, Albert D. Cahalan wrote:
> > Rob Landley writes:
> > > My only real gripe with Linux's threads right now [...] is
> > > that ps and top and such aren't thread aware and don't group them
> > > right.
> > >
> > > I'm told they added some kind of "threadgroup" field to processes
> > > that allows top and ps and such to get the display right.  I haven't
> > > noticed any upgrades, and haven't had time to go hunting myself.
> >
> > There was a "threadgroup" added just before the 2.4 release.
> > Linus said he'd remove it if he didn't get comments on how
> > useful it was, examples of usage, etc. So I figured I'd look at
> > the code that weekend, but the patch was removed before then!
> 
> Can we give him feedback now, asking him to put it back?
> 
> > Submit patches to me, under the LGPL please. The FSF isn't likely
> > to care. What, did you think this was the GNU system or something?
> 
> I've stopped even TRYING to patch bash.  try a for loop calling "echo $$&", 
> eery single process bash forks off has the PARENT'S value for $$, which is 
> REALLY annoying if you spend an afternoon writing code not knowing that and 
> then wonder why the various process's temp file sare stomping each other...

Actually - you have an error there. $$ gets evaluated during the parse, not
during execution of the subprocess. To get what you are describing it is
necessary to "sh -c 'echo $$'" to force the delay of evaluation. The only
"bug" interpretation is in the evaluation of the quotes. IF echo '$$' &
delayed the interpretation of "$$", then when the subprocess shell
"echo $$" reparsed the line the $$ would be substituted as you wanted.
This delay can only be done via the "sh -c ..." method. (its the same with
bourne/korn shell).

> Oh, and anybody who can explain this is welcome to try:
> 
> lines=`ls -l | awk '{print "\""$0"\""}'`
> for i in $lines
> do
>   echo line:$i
> done

That depends on what you are trying to do. Are you trying to echo the
entire "ls -l"? or are you trying to convert an "ls -l" into a single
column based on a field extracted from "ls -l".

If the latter, then the script should be:

ls -l | awk '{print $<fieldno>}' | while read i
do
    echo line: $i
done

If the fields don't matter, but you want each line processed in the
loop do:

ls -l | while read i
do
   echo line:$i
done

Bash doesn't need patching for this.

Again, the evaluation of the quotes is biting you. When the $lines
parameter is evaluated, the quotes are present.

bash is doing a double evaluation for "for" loop. It expects
a list of single tokens, rather than a list of quoted strings. This is
the same as in the bourne/korn shell.

If you want such elaborate handling of strings, I suggest using perl.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rusty Russell]

In message <Pine.GSO.4.21.0106201429150.26389-100000@weyl.math.psu.edu> you wri
te:
> In practice it's a BS. There is a lot of ways minor modifications of code
> could add a preemption point, so if you rely on the lack of such - expect
> major PITA.
> 
> Yes, in theory SMP adds some extra fun. Practically, almost every "SMP"
> race found so far did not require SMP.

Disagree.  A significant percentage of the netfilter bugs have been
SMP only (the whole thing is non-reentrant on UP).

Depends what part of the kernel you play in,
Rusty.
--
Premature optmztion is rt of all evl. --DK

Re: Alan Cox quote? (was: Re: accounting for threads)

[D. Stimits]

Rob Landley wrote:
> 
> On Wednesday 20 June 2001 20:42, D. Stimits wrote:
> > Rob Landley wrote:
> > ...snip...
> >
> > > The patches-linus-actuall-applies mailing list idea is based on how Linus
> > > says he works: he appends patches he likes to a file and then calls patch
> > > -p1 < thatfile after a mail reading session.  It wouldn't be too much
> > > work for somebody to write a toy he could use that lets him work about
> > > the same way but forwards the messages to another folder where they can
> > > go out on an otherwise read-only list.  (No extra work for Linus.  This
> > > is EXTREMELY important, 'cause otherwise he'll never touch it.)
> >
> > What if the file doing patches from is actually visible on a web page?
> > Or better yet, if the patch command itself was modified such that at the
> > same time it applies a patch, the source and the results were added to a
> > MySQL server which in turn shows as a web page?
> 
> His patch file already has a bunch of patches glorped together.  In theory
> they could be separated again by parsing the mail headers.  I suppose that
> would be less work for Linus...
> 
> The point is, the difference between the patches WE get and the patches LINUS
> gets is the granularity.  He's constantly extorting other people to watch the
> granularity of what they send him (small patches, each doing one thing, with
> good documentation as to what they do and why, in seperate messages), but
> what WE get is a great big diff about once a week.

If patch was itself modified, the one big patch file could easily be
considered in terms of all of its smaller patches in any processing it
does as a publication aid.

> 
> So what I'm trying to figure out is if we can impose on Linus to cc: a
> mailing list on the stream of individual patch messages he's applying to his
> tree, so we can follow it better.  And he IS willing to do a LITTLE work for
> us.  He's issuing changelogs now.  This would be significantly less effort
> than that...

The patch command already considers one large file to be a lot of
smaller patches in most cases. Why not, as it does its work, let it
document what it has done?

> 
> MySQL is overkill, and since these things started as mail messages why should
> they be converted into a foriegn format?  There's threaded archivers for
> mailing lists and newsgroups and stuff already, why reinvent the wheel?

MySQL is just a sample. I mention it because it is quite easy to link a
web server to. Imagine patch running on a large file that is a
conglomeration of 50 small patches; it could easily summarize this, and
storing it through MySQL adds a lot of increased web flexibility (such
as searching and sorting). It is, however, just one example of a way to
make "patch" become autodocumenting.

> 
> Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[D. Stimits]

Rob Landley wrote:
...snip...
> The patches-linus-actuall-applies mailing list idea is based on how Linus
> says he works: he appends patches he likes to a file and then calls patch -p1
> < thatfile after a mail reading session.  It wouldn't be too much work for
> somebody to write a toy he could use that lets him work about the same way
> but forwards the messages to another folder where they can go out on an
> otherwise read-only list.  (No extra work for Linus.  This is EXTREMELY
> important, 'cause otherwise he'll never touch it.)

What if the file doing patches from is actually visible on a web page?
Or better yet, if the patch command itself was modified such that at the
same time it applies a patch, the source and the results were added to a
MySQL server which in turn shows as a web page?

Re: Alan Cox quote? (was: Re: accounting for threads)

[Dan Podeanu]

export IFS=$'\n'

> lines=`ls -l | awk '{print "\""$0"\""}'`
> for i in $lines
> do
>   echo line:$i
> done

Re: Alan Cox quote? (was: Re: accounting for threads)

[Albert D. Cahalan]

Rob Landley writes:

> My only real gripe with Linux's threads right now [...] is
> that ps and top and such aren't thread aware and don't group them
> right.
>
> I'm told they added some kind of "threadgroup" field to processes
> that allows top and ps and such to get the display right.  I haven't
> noticed any upgrades, and haven't had time to go hunting myself.

There was a "threadgroup" added just before the 2.4 release.
Linus said he'd remove it if he didn't get comments on how
useful it was, examples of usage, etc. So I figured I'd look at
the code that weekend, but the patch was removed before then!

There is nothing that ps and top can do about this problem.
I've certainly looked into the matter; much of the code is mine.
BTW, the version in debian-unstable is the most stable. :-)

These options might help a little bit: --forest -H f

> (Ever tried to sumit a patch to the FSF?  They want you to sign
> legal documents.  That's annoying.  I usually just send the bug
> reports to red hat and let THEM deal with it...)

Submit patches to me, under the LGPL please. The FSF isn't likely
to care. What, did you think this was the GNU system or something?

> Linus's job is to keep code OUT of the kernel.  He has veto power,
> nothing else.  I suspect he's pre-emptively vetoing some stuff to
> keep the flood down to a level he can deal with.  Maybe someday
> we'll convince him to use some variant of source control (not
> necessarily CVS, how about just a seperate mailing list of the
> individual patches as he applies them?  One linus can post to and
> that is read-only to everybody else?  HE always wants patches
> seperated down nicely into individual messages with explanations,
> but WE have to get pre2-pre3 as one big patch lump.  With a
> patches-from-linus mailing list that he forwarded posts to, we'd
> know exactly when a patch went in and who it was from without
> bothering Linus. :)

How about a filesystem filter to spit out patches, or a filesystem
interface to version control?

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Wednesday 20 June 2001 20:42, D. Stimits wrote:
> Rob Landley wrote:
> ...snip...
>
> > The patches-linus-actuall-applies mailing list idea is based on how Linus
> > says he works: he appends patches he likes to a file and then calls patch
> > -p1 < thatfile after a mail reading session.  It wouldn't be too much
> > work for somebody to write a toy he could use that lets him work about
> > the same way but forwards the messages to another folder where they can
> > go out on an otherwise read-only list.  (No extra work for Linus.  This
> > is EXTREMELY important, 'cause otherwise he'll never touch it.)
>
> What if the file doing patches from is actually visible on a web page?
> Or better yet, if the patch command itself was modified such that at the
> same time it applies a patch, the source and the results were added to a
> MySQL server which in turn shows as a web page?

His patch file already has a bunch of patches glorped together.  In theory 
they could be separated again by parsing the mail headers.  I suppose that 
would be less work for Linus...

The point is, the difference between the patches WE get and the patches LINUS 
gets is the granularity.  He's constantly extorting other people to watch the 
granularity of what they send him (small patches, each doing one thing, with 
good documentation as to what they do and why, in seperate messages), but 
what WE get is a great big diff about once a week.

So what I'm trying to figure out is if we can impose on Linus to cc: a 
mailing list on the stream of individual patch messages he's applying to his 
tree, so we can follow it better.  And he IS willing to do a LITTLE work for 
us.  He's issuing changelogs now.  This would be significantly less effort 
than that...

MySQL is overkill, and since these things started as mail messages why should 
they be converted into a foriegn format?  There's threaded archivers for 
mailing lists and newsgroups and stuff already, why reinvent the wheel?

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Cort Dougan]

Don't forget the linux-kernel favorite, "Debuggers are for bad
programmers".

} Here are more from the same basket you obviously got the first quote from:
} 
} ------------------------------------
} Virtual memory is only for unskilled programmers who don't know how to use
} overlays.
} ------------------------------------
} Protected memory is a constant 10% CPU hog needed only by undisciplined
} programmers who can't keep their memory writes in their own process space.
} ------------------------------------

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Wednesday 20 June 2001 11:33, Alexander Viro wrote:
> On 20 Jun 2001, Jes Sorensen wrote:
> > Not to mention how complex it is to get locking right in an efficient
> > manner. Programming threads is not that much different from kernel SMP
> > programming, except that in userland you get a core dump and retry, in
> > the kernel you get an OOPS and an fsck and retry.
>
> Arrgh. As long as we have that "SMP makes locking harder" myth floating
> around we _will_ get problems. Kernel UP programming is not different
> from SMP one. It is multithreaded. And amount of genuine SMP bugs is
> very small compared to ones that had been there on UP since way back.
> And yes, programming threads is the same thing. No arguments here.

Hopefully in 2.5 we'll get the pre-emptive UP patch in that enables the SMP 
locks on UP and finally clean it all out by exposing the bugs to the main 
user base.

As for multi-threaded programming being hard, people are unfamiliar with it.  
Any programming is hard the first time.  And almost anybody's first attempt 
at it is going to suck.  (Dig out the linux kernel 0.02 sources sometime and 
compare them with what we have today.)

The more experience you get with it, the better you are.  Encouraging people 
to stay away from it rather than learn to do it RIGHT is the wrong attitude.  
People will figure out that using 1000 threads when you need 3 isn't the best 
way to go, that locking is an expense but failing to lock is worse, how to 
spot race conditions (the same old "security" mindset except you don't need a 
malicious third party to get bitten by it.)

And they'll learn it the way I did, and the way everybody does.  Do it wrong 
repeatedly.  Make every mistake there is, hard.  Get burned, rewrite it from 
scratch four times until you figure out how to design it right, spend long 
weekends looking for subtle little EVIL bugs you can't reproduce but which 
bite you the instant you stop looking for them, learn to play "hot potato" 
with volatile data you have to manipulate atomically...

Everybody starts as a bad programmer.  Some of us get it out of our systems 
when we're 12.  Others decide programming is lucrative when they're 35 and 
inflict their "hello world" opus upon their coworkers.  Me, I wrote a disk 
editor and a bunch of bbses in 5th and 6th grade back on the C64 that will 
never see the light of day.  And yes they sucked.  But I'm still proud of 
them.  And I wrote awful multithreaded code back on OS/2, and can now write 
decent threading code because I've learned a large number of things to avoid 
doing.  And I take proper care because I know how hard it is to FIND one of 
these if you do wind up doing it.  I've done it.  Once for two consecutive 
weeks on the same #%*(&#%& bug.  There's no WAY somebody's going to pick that 
sort of thing up in a programming course, or from "advice" from experienced 
people.  We never listen to advice from experienced programmers.  If we did 
we'd still be using Fortran for everything...

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rok Papež]

Hi!

It's hard not to reply to this kind of message but there is so much
"anti-thread hype" here that someone obviously has to stand up to it.
This reply isn't aimed just at Larry but at all the anti-thread-rant
people with 0 threads == 0 problems attitude.

On Tuesday 19 June 2001 18:09, Larry McVoy wrote:
>     "If you think you need threads then your processes are too fat"
>     ``Think of it this way: threads are like salt, not like pasta. You
>     like salt, I like salt, we all like salt. But we eat more pasta.''

Here are more from the same basket you obviously got the first quote from:

------------------------------------
Virtual memory is only for unskilled programmers who don't know how to use
overlays.
------------------------------------
Protected memory is a constant 10% CPU hog needed only by undisciplined
programmers who can't keep their memory writes in their own process space.
------------------------------------

> Threads are a really bad idea.

I could *say* the same about Alans co-routines and Async IO :-). But it
would be foolish of me to criticize something I haven't used.

There is more than one way how to skin a dinosaur. And threads are one
way of doing it. You don't like it ? FINE. But don't go bashing it.

Probably most people bash threads becouse of a silly way POSIX designed
(designed is an overstatement) their pthread API and becouse UNIX was
around before threads thus probably making every UNIX thread support a
hacked and not a designed tool.
Other OSes have certainly proven threads to be nice and usable.

And here is another one for you quotes page:
------------------------------------
If you can't stick your head out of your own backyard please... don't
go and crtiticize the world... :-)
------------------------------------

-- 
best regards,
Rok Papež.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Victor Yodaiken]

On Tue, Jun 19, 2001 at 09:52:39AM -0700, Larry McVoy wrote:
> I think the general thrust of us ``anti-thread'' people is that a few
> are fine, a lot is stupid, and the model encourages a lot.  It's just

There is a huge academic research literature on how to prove that a large
set of threads will all meet deadlines in a realtime system.  Years ago I
made a not-so-brilliant optimization to RTLinux scheduler that had an unanticipated
side effect of only scheduling the first two threads created. Nobody noticed
for months, because RT programmers know that more than 2 threads is 
almost always a design error.  Not always though.
(now we have regression tests so I could not make such an experiment again).

Re: Alan Cox quote? (was: Re: accounting for threads)

[Victor Yodaiken]

On Tue, Jun 19, 2001 at 08:18:59PM +0100, Alan Cox wrote:
> There I disagree. Threads introduce parallelism that the majority of user
> space programmers have trouble getting right (not that C is helpful here).

I think it depends on the application. In the RT space the concept
	Do this every millisecond starting now
	Do this every 500 us starting in 30 microseconds
is pretty clear and simple.

> A threaded program has a set of extremely complex hard to repeat timing based
> behaviour dependancies. An unthreaded app almost always does the same thing on
> the same input. From a verification and coverage point of view that is 
> incredibly important.

Depends on the design. I'm sure you've seen some impressively obscure examples of the
"do everything in an event loop" style of programming that is common in embedded.

To me this is like the arguments people used to have over recursion and the answer is
the same:

	Bad programmers can make any programming construct worse

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On Wed, 20 Jun 2001, george anzinger wrote:

> > around we _will_ get problems. Kernel UP programming is not different
> > from SMP one. It is multithreaded. And amount of genuine SMP bugs is
> > very small compared to ones that had been there on UP since way back.
> > And yes, programming threads is the same thing. No arguments here.
> > 
> Correct, IF the UP kernel is preemptable.  As long as it is not (and SMP
> is ignored) threads are harder BECAUSE they are preemptable.

In practice it's a BS. There is a lot of ways minor modifications of code
could add a preemption point, so if you rely on the lack of such - expect
major PITA.

Yes, in theory SMP adds some extra fun. Practically, almost every "SMP"
race found so far did not require SMP.

Clean code is trivial to make SMP-safe - critical areas that rely on
lack of preemption are couple of instructions wide and are easy to
protect. Anything trickier and I bet that you have a race on (normal)
UP kernel. Been there, found probably several hundreds of them.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Wednesday 20 June 2001 17:20, Albert D. Cahalan wrote:
> Rob Landley writes:
> > My only real gripe with Linux's threads right now [...] is
> > that ps and top and such aren't thread aware and don't group them
> > right.
> >
> > I'm told they added some kind of "threadgroup" field to processes
> > that allows top and ps and such to get the display right.  I haven't
> > noticed any upgrades, and haven't had time to go hunting myself.
>
> There was a "threadgroup" added just before the 2.4 release.
> Linus said he'd remove it if he didn't get comments on how
> useful it was, examples of usage, etc. So I figured I'd look at
> the code that weekend, but the patch was removed before then!

Can we give him feedback now, asking him to put it back?

> Submit patches to me, under the LGPL please. The FSF isn't likely
> to care. What, did you think this was the GNU system or something?

I've stopped even TRYING to patch bash.  try a for loop calling "echo $$&", 
eery single process bash forks off has the PARENT'S value for $$, which is 
REALLY annoying if you spend an afternoon writing code not knowing that and 
then wonder why the various process's temp file sare stomping each other...

Oh, and anybody who can explain this is welcome to try:

lines=`ls -l | awk '{print "\""$0"\""}'`
for i in $lines
do
  echo line:$i
done

> How about a filesystem filter to spit out patches, or a filesystem
> interface to version control?

Explain please?

The patches-linus-actuall-applies mailing list idea is based on how Linus 
says he works: he appends patches he likes to a file and then calls patch -p1 
< thatfile after a mail reading session.  It wouldn't be too much work for 
somebody to write a toy he could use that lets him work about the same way 
but forwards the messages to another folder where they can go out on an 
otherwise read-only list.  (No extra work for Linus.  This is EXTREMELY 
important, 'cause otherwise he'll never touch it.)

The advantage of this way is:

1) We know who sent the patches.  (We get the message with the "from" headers 
intact.)

2) Patch mails have descriptions in them most of the time, at least saying 
why, if not what they do.

3) This way, we know (more or less in realtime) that Linus has gotten a patch 
and applied it to his tree.  (What version and everything.)  It may be backed 
out again later, but we could give him another tool that can do that and 
notify the list...

This way, no mucking about with version control, no extra work for Linus, and 
in fact he doesn't have to worry about keeping track of what patches he's 
applied and when because he has a place he can go check if he forgets.

Now everybody tell me why this won't work. (Sure, all at once, why not...)

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Wed, Jun 20, 2001 at 08:21:30PM +1000, john slee wrote:
> On Tue, Jun 19, 2001 at 08:04:42PM -0700, Larry McVoy wrote:
> > I asked Linus for this a long time ago and he pointed out that you couldn't
> > make it work over NFS, at least not nicely.  It does seem like that could
> > be worked around by having a "poll daemon" which knew about all the things
> > being waited on and checked them.  Or something.
> 
> could sgi's imon+fam work help a little here (with the "poll daemon" part)?
> am i on the wrong train ? :-]

I was never a fan of that tool though SGI people loved it.  I think that 
someone needs to grab this area and think it through.  There ought to be
some way to do this that isn't gross.  But it will take some thinking.  
If you could convince one of the file system guys to think about this for
a week I suspect you'd get something nice.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jes Sorensen]

>>>>> "Al" == Alexander Viro <viro@math.psu.edu> writes:

Al> On 20 Jun 2001, Jes Sorensen wrote:

>> Not to mention how complex it is to get locking right in an
>> efficient manner. Programming threads is not that much different
>> from kernel SMP programming, except that in userland you get a core
>> dump and retry, in the kernel you get an OOPS and an fsck and
>> retry.

Al> Arrgh. As long as we have that "SMP makes locking harder" myth
Al> floating around we _will_ get problems. Kernel UP programming is
Al> not different from SMP one. It is multithreaded. And amount of
Al> genuine SMP bugs is very small compared to ones that had been
Al> there on UP since way back.  And yes, programming threads is the
Al> same thing. No arguments here.

Call it SMP or kernel threading, I don't really care, it's the same
thing. My point is that in the kernel you must take threading/SMP into
account when coding and yes it's not trivial to do it efficiently
(though often fairly easy to do it inefficiently) and the same applies
to userland threads. Userland threads are just not some chest of gold
that just opens up a free path to paradise as most CS teachers seems
to promote it as being.

Jes

Re: Alan Cox quote? (was: Re: accounting for threads)

[george anzinger]

Alexander Viro wrote:
> 
> On 20 Jun 2001, Jes Sorensen wrote:
> 
> > Not to mention how complex it is to get locking right in an efficient
> > manner. Programming threads is not that much different from kernel SMP
> > programming, except that in userland you get a core dump and retry, in
> > the kernel you get an OOPS and an fsck and retry.
> 
> Arrgh. As long as we have that "SMP makes locking harder" myth floating
> around we _will_ get problems. Kernel UP programming is not different
> from SMP one. It is multithreaded. And amount of genuine SMP bugs is
> very small compared to ones that had been there on UP since way back.
> And yes, programming threads is the same thing. No arguments here.
> 
Correct, IF the UP kernel is preemptable.  As long as it is not (and SMP
is ignored) threads are harder BECAUSE they are preemptable.

George

Re: Alan Cox quote? (was: Re: accounting for threads)

[Davide Libenzi]

On 20-Jun-2001 Larry McVoy wrote:
> On Tue, Jun 19, 2001 at 10:57:38PM -0400, Michael Rothwell wrote:
>> On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote:
>> 
>> > Linux inherits several unix properties which are not friendly to good
>> > state
>> > based programming - lack of good AIO for one.
>> 
>> Oh, how I would love for select() and poll() to work on files... or for
>> any other working AIO mothods to be present.
>> 
>> What would get broken if things were changed to let select() work for
>> filesystem fds?
> 
> I asked Linus for this a long time ago and he pointed out that you couldn't
> make it work over NFS, at least not nicely.  It does seem like that could 
> be worked around by having a "poll daemon" which knew about all the things
> being waited on and checked them.  Or something.
> 
> I'd like it too.  And I'd like a callback for iocompletion, a way to do
> preread(fd, len).

I'll be more than happy to have IO completion only at socket level.
Something like :


struct iocompletion ioc;

fcntl(sfd, F_SETFL, fcntl(sfd, F_GETFL, 0) | O_NONBLOCK);

ioc.event = IOC_READ;
ioc.callback = data_ready;
ioc.data = session_data;

fcntl(sfd, F_ADDIOC, (long) &ioc);


This would be pretty nice.




- Davide

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On 20 Jun 2001, Jes Sorensen wrote:

> Not to mention how complex it is to get locking right in an efficient
> manner. Programming threads is not that much different from kernel SMP
> programming, except that in userland you get a core dump and retry, in
> the kernel you get an OOPS and an fsck and retry.

Arrgh. As long as we have that "SMP makes locking harder" myth floating
around we _will_ get problems. Kernel UP programming is not different
from SMP one. It is multithreaded. And amount of genuine SMP bugs is
very small compared to ones that had been there on UP since way back.
And yes, programming threads is the same thing. No arguments here.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jes Sorensen]

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> But that foregoes the point that the code is far more complex and
>> harder to make 'obviously correct', a concept that *does* translate
>> well to userspace.

Alan> There I disagree. Threads introduce parallelism that the
Alan> majority of user space programmers have trouble getting right
Alan> (not that C is helpful here).

Alan> A threaded program has a set of extremely complex hard to repeat
Alan> timing based behaviour dependancies. An unthreaded app almost
Alan> always does the same thing on the same input. From a
Alan> verification and coverage point of view that is incredibly
Alan> important.

Not to mention how complex it is to get locking right in an efficient
manner. Programming threads is not that much different from kernel SMP
programming, except that in userland you get a core dump and retry, in
the kernel you get an OOPS and an fsck and retry.

For some reason CS professors decided that threads were the cool thing
to do and started teaching all their students to program threadded
applications. Unfortunately they did forget to teach about the caveats
and all the funny side effects that generally mostly threadded apps a
really stupid idea.

It's been like this for some years now, one would expect a switch to
another buzzword of the year paradigm from them soon.

Jes

Re: Alan Cox quote? (was: Re: accounting for threads)

[Matthias Urlichs]

At 18:31 -0500 2001-06-19, Timur Tabi wrote:
>Not quite.  What makes OS/2's threads superior is that the OS multitasks
>threads, not processes.  So I can create a time-critical thread in my process,
>and it will have priority over ALL threads in ALL processes.

In contrast to Linux, which does exactly the same thing -- so what 
are you trying to tell us?

>A lot of OS/2 software is written with this feature in mind.  I know of one
>programmer who absolutely hates Linux because it's just too difficult porting
>software to it, and the lack of decent thread support is part of the problem.

So what would you consider to be "decent thread support"?

-- 
Matthias Urlichs

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mike Porter]

> But that foregoes the point that the code is far more complex and harder to
> make 'obviously correct', a concept that *does* translate well to userspace.

One point is that 'obviously correct' is much harder to 'prove' for
threads (or processes with shared memory) than you might think.
With a state machine, you can 'prove' that object accesses won't
conflict much more easily.  With a threaded or process based model,
you have to spend considerable time thinking about multiple readers
and writers and locking.

One metric I use to evaluate program complexity is how big of a
headache I get when trying to prove something "correct".
Multi-process or multi-threaded code hurts more than a well written
state machine.

Mike

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Wednesday 20 June 2001 10:35, Mike Porter wrote:
> > But that foregoes the point that the code is far more complex and harder
> > to make 'obviously correct', a concept that *does* translate well to
> > userspace.
>
> One point is that 'obviously correct' is much harder to 'prove' for
> threads (or processes with shared memory) than you might think.
> With a state machine, you can 'prove' that object accesses won't
> conflict much more easily.  With a threaded or process based model,
> you have to spend considerable time thinking about multiple readers
> and writers and locking.
>
> One metric I use to evaluate program complexity is how big of a
> headache I get when trying to prove something "correct".
> Multi-process or multi-threaded code hurts more than a well written
> state machine.

The same applies to security though.  There's programmers out there we're 
unwilling to give the tools to create race conditions, but we expect them to 
write stuff that won't allow a box on the internet to be own3d in under 24 
hours...

Obvious isn't always correct...

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Tuesday 19 June 2001 19:31, Timur Tabi wrote:

> Amen.  This is one of the reasons why I also prefer OS/2 over Linux.

Preferred.

OS/2's day has come and gone.  IBM killed it with a stupid diversion into the 
power PC version between 1993 and 1995.  By the time Windows 95 was released, 
MS had finally (after 11 years) managed to properly clone the original 1984 
macintosh, and 90% of the PC user base was no longer actively looking to 
replace their OS (Windows 3.1 and/or DOS).  The window of opportunity for a 
proprietary OS to replace Microsoft's had closed, and OS/2 4.0 was just plain 
too late.  (If it had been released two years earlier, things might have been 
different.  But it wasn't.)

But the window to commoditize a propreitary niche never closes.  The PC 
clones didn't care whether digital's minicomputers or IBM's mainframes won 
out in the marketplace, they were quite happy to replace both.  Linux is 
winning because it's free software, not for whatever transient technical 
reasons make one version of an OS better than another on a given day.

> Feature Installer is a bad example.  That software is a piece of crap for
> lots of reasons, excessive threading being only one, and every OS/2 user
> knew it the day it was released.  Why do you think WarpIN was created?

I know, and I'm sorry I rescued FI from the corpse of OS/2 for the Power PC.  
But it was my job, you know. :)  (And I did rewrite half of it from scratch.  
Before that it didn't work at ALL.  There were algorithms in there that 
scaled (failed to scale) to n^n complexity on the object hierarchy.  
Unfortunately, IBM wouldn't let me rewrite the other half of it, and most of 
that was pretty darn obnoxious and evil.)

Isn't it interesting that OS/2 turned into a unix platform?  (EMX and gcc, 
where all the software was coming from?  I think I tried to point that out to 
you when I attempted to recruit you into the LInux world at that gaming 
session at armadillocon in... 1999?  Glad to see you did eventually come over 
to the chocolate side of the force after all... :)

> Not quite.  What makes OS/2's threads superior is that the OS multitasks
> threads, not processes.  So I can create a time-critical thread in my
> process, and it will have priority over ALL threads in ALL processes.

And in Linux you can create a time-critical process that shares large gorps 
of memory where you keep your global variables, and call it a thread, and it 
works the same way.

My only real gripe with Linux's threads right now (other than the fact they 
keep trying to get us to use the posix api, which sucks.  What IS an event 
variable.  What's wrong with event semaphores?) is that ps and top and such 
aren't thread aware and don't group them right.

I'm told they added some kind of "threadgroup" field to processes that allows 
top and ps and such to get the display right.  I haven't noticed any 
upgrades, and haven't had time to go hunting myself.  (Ever tried to sumit a 
patch to the FSF?  They want you to sign legal documents.  That's annoying.  
I usually just send the bug reports to red hat and let THEM deal with it...)

> A lot of OS/2 software is written with this feature in mind.  I know of one
> programmer who absolutely hates Linux because it's just too difficult
> porting software to it, and the lack of decent thread support is part of
> the problem.

Yup.  OS/2 is the largest nest of trained, experienced multi-threaded 
programmers.  (And it takes a LOT of training experience to do threads 
right.)  That's why I've been trying to recruit ex-OS/2 guys over to Linux 
for years now.  (Most followed Java to Linux after Netscape opened up 
Mozilla, but there used to be several notable holdouts...)

Threading is just another way to look at programming, with both advantages 
and disadvantages.  You get automatic SMP scalability that's quite nice if 
you keep cache coherency in mind.  You get great latency and responsiveness 
in user interfaces with just one or two extra threads.  (State machines may 
be superior if implemented perfectly, but like co-operative multitasking 
(which they are) it's trivially easy to block the suckers and hang the whole 
GUI.  If you hang one thread, you can even program another thread to notice 
automatically and unwedge it without much overhead at all.  Trying to unwedge 
a state machine is a little more complicated than kill/respawn of a thread.  
Of course a perfect state machine shouldn't have those problems, but when you 
interface with other people's code in a large system, you accept imperfection 
and make the system survive as best it can.)

> Exactly.  Saying that threads cause bad code is just as dumb as saying that
> a kernel debugger will cause bad code because programmers will start using
> the debugger instead of proper design.
>
> Oh wait, never mind .....

Ah, don't pick on Linus.  It's not exactly like the limiting factor to kernel 
development is a SHORTAGE of patches sent in to the various maintainers.

Linus's job is to keep code OUT of the kernel.  He has veto power, nothing 
else.  I suspect he's pre-emptively vetoing some stuff to keep the flood down 
to a level he can deal with.  Maybe someday we'll convince him to use some 
variant of source control (not necessarily CVS, how about just a seperate 
mailing list of the individual patches as he applies them?  One linus can 
post to and that is read-only to everybody else?  HE always wants patches 
seperated down nicely into individual messages with explanations, but WE have 
to get pre2-pre3 as one big patch lump.  With a patches-from-linus mailing 
list that he forwarded posts to, we'd know exactly when a patch went in and 
who it was from without bothering Linus. :)

Maybe something like that would allow a bit more decentralization, and then 
he'd feel like he could keep his head above water if he allowed in a kernel 
debugger.  Who knows?

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[john slee]

On Tue, Jun 19, 2001 at 08:04:42PM -0700, Larry McVoy wrote:

[ ... ]

> I asked Linus for this a long time ago and he pointed out that you couldn't
> make it work over NFS, at least not nicely.  It does seem like that could
> be worked around by having a "poll daemon" which knew about all the things
> being waited on and checked them.  Or something.

could sgi's imon+fam work help a little here (with the "poll daemon" part)?
am i on the wrong train ? :-]

not sure how maintained it is these days...

[ ... ]

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alan Cox]

> Oh, how I would love for select() and poll() to work on files... or for
> any other working AIO mothods to be present.
> What would get broken if things were changed to let select() work for
> filesystem fds?

It does. They are always readable. If it were to trigger prefetching in that
case then I suspect no harm would occur

Re: Alan Cox quote? (was: Re: accounting for threads)

[Henning P. Schmiedehausen]

Larry McVoy <lm@bitmover.com> writes:

> [...] died-in-the-wool Java programmer and could care less about
> performance, system design, or any elegance whatsoever.

Larry, please.

SunOS _is_ dead [1]. Ever since they switched to Solaris, you seem to
be sore about Si^hun and everything that comes out of them [3] :-)

If it wasn't for Java, 99% of the commercial world today would be
Visual Basic. So, please, stop bashing on it just because you're not
using it.

All operating systems suck. All languages suck. Everyone can write bad
code in every language. It's neither a question of a language or OS
but of developer skill and experience.

Just the fact that some people use Java (or any other language) does
not mean, that they don't care about "performance, system-design or
any elegance whatsoever" [2].

	Regards
		Henning

[1] I still have a SunOS 4.1.4_patched_to_the_hell_and_back box at a
customer site and this single box gives us more headaches performance-
, stability and security wise than any of the 10+ Solaris 2.7 or 25+
Linux boxes. It's a sucker to keep the newbie admins awake, that there
were things before bash, linuxconf and /sbin/chkconfig. Compiling an
OpenSSH on this box made at least one of the newbies quit. =;-)

[2] I was raised on SunOS 4.0.3 and I'm glad to have Solaris+Linux. I
did an OS innards course at the university around 1991/1992 and they
had a license to give the students a look into the source code of
SunOS at this time. I had nightmares for weeks after. Horrors after
horrors to sacrifice "system-design and elegance" for "performance".

[3] Please. It starts sounding like the nostalgia some east germans
develop to get their totalitarian regime back, because "everything was
better then".


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Alan Cox quote? (was: Re: accounting for threads)

[John R Lenton]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

On Tue, Jun 19, 2001 at 08:04:42PM -0700, Larry McVoy wrote:
> On the other hand, the fact that it doesn't exist on other platforms sort
> of means that it isn't going anywhere.  In a sick sort of way, the most
> likely way to make this happen is to get Microsoft to do it and then Linux
> will do it as well and then the Solaris jocks will also fall in line.  The
> only problem with that is that Microsoft can't design an OS interface to save 
> their lives, so maybe Linux _should_ do it first.

world domination has to start somewhere...

-- 
John Lenton (john@grulic.org.ar) -- Random fortune:
Tu amigo tiene un amigo, y el amigo de tu amigo tiene otro amigo; por consiguiente, sé discreto.
		-- Proverbio judío. 

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 10:57:38PM -0400, Michael Rothwell wrote:
> On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote:
> 
> > Linux inherits several unix properties which are not friendly to good state
> > based programming - lack of good AIO for one.
> 
> Oh, how I would love for select() and poll() to work on files... or for
> any other working AIO mothods to be present.
> 
> What would get broken if things were changed to let select() work for
> filesystem fds?

I asked Linus for this a long time ago and he pointed out that you couldn't
make it work over NFS, at least not nicely.  It does seem like that could 
be worked around by having a "poll daemon" which knew about all the things
being waited on and checked them.  Or something.

I'd like it too.  And I'd like a callback for iocompletion, a way to do
preread(fd, len).

On the other hand, the fact that it doesn't exist on other platforms sort
of means that it isn't going anywhere.  In a sick sort of way, the most
likely way to make this happen is to get Microsoft to do it and then Linux
will do it as well and then the Solaris jocks will also fall in line.  The
only problem with that is that Microsoft can't design an OS interface to save 
their lives, so maybe Linux _should_ do it first.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Michael Rothwell]

On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote:

> Linux inherits several unix properties which are not friendly to good state
> based programming - lack of good AIO for one.

Oh, how I would love for select() and poll() to work on files... or for
any other working AIO mothods to be present.

What would get broken if things were changed to let select() work for
filesystem fds?

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mike Castle]

On Tue, Jun 19, 2001 at 06:30:54PM -0700, Ben Greear wrote:
> Yeah, and we are young and prolific too, so you better watch out! :)

Prolific != competent.
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Alan Cox quote? (was: Re: accounting for threads)

[Ben Greear]

Larry McVoy wrote:
> 

> Good question but I doubt we're going to get anywhere.  Anyone who thinks
> that 73MB of RAM is an OK thing to waste on window system is probably a
> died-in-the-wool Java programmer and could care less about performance,
> system design, or any elegance whatsoever.

Bleh, don't go taking cheap shots at Java!  Java is good at what it does,
memory and performance be damned!

> It pains me to believe that people like this exist but there they are.

Yeah, and we are young and prolific too, so you better watch out! :)

Ben

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: Alan Cox quote? (was: Re: accounting for threads)

[Robert Love]

On 19 Jun 2001 18:04:21 -0600, Chris Ricker wrote:
> It's a very impressive difference:
><snip>
> Process fork+exit: 563.7778 microseconds
><snip>
> Process fork+exit: 4249.5000 microseconds

_WOW_ -- i think you just ended that discussion... wow.

Robert M. Love
rml@ufl.edu
rml@tech9.net

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 05:19:45PM -0700, Mike Castle wrote:
> On Tue, Jun 19, 2001 at 04:56:16PM -0700, Jonathan Lundell wrote:
> > But so what? That's $16 worth of DRAM (I just checked). Not so bad 
> > *if* threads are otherwise a great solution. I grant that one might 
> > have a pretty tough time making the case, but again, for the right 
> > application, say some app with a dedicated server, 73MB isn't the end 
> > of the world (though I suppose it was at the time...).
> 
> How much would 73MB of cache cost?  How much would it cost to get that much
> on the CPU?

Good question but I doubt we're going to get anywhere.  Anyone who thinks
that 73MB of RAM is an OK thing to waste on window system is probably a
died-in-the-wool Java programmer and could care less about performance,
system design, or any elegance whatsoever.

It pains me to believe that people like this exist but there they are.
What can you do?  As Confucius says "If I hold up three corners of a square
and the student does not hold up the fourth, I do not bother to go over
the point again".
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mike Castle]

On Tue, Jun 19, 2001 at 04:56:16PM -0700, Jonathan Lundell wrote:
> But so what? That's $16 worth of DRAM (I just checked). Not so bad 
> *if* threads are otherwise a great solution. I grant that one might 
> have a pretty tough time making the case, but again, for the right 
> application, say some app with a dedicated server, 73MB isn't the end 
> of the world (though I suppose it was at the time...).


How much would 73MB of cache cost?  How much would it cost to get that much
on the CPU?

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Alan Cox quote? (was: Re: accounting for threads)

[Chris Ricker]

On Tue, 19 Jun 2001, David S. Miller wrote:

> <axe_grind>
>
> Don't believe me that Solaris sucks here?  Run this experiment under
> Solaris-latest and Linux on a sparc64 system (using lmbench):
>
> Under Solaris: ./lat_proc fork
> Under Linux: strace -f ./lat_proc fork
>
> I bet the Linux case does better than the Solaris run by some orders
> of magnitude.  That's how poor their fork/exit/switch code is.
>
> </axe_grind>

It's a very impressive difference:

Script started on Tue Jun 19 17:49:30 2001
[kaboom@thing2 linux]$ ./lat_proc fork
Process fork+exit: 563.7778 microseconds
[kaboom@thing2 linux]$ ./lat_proc fork
Process fork+exit: 565.5556 microseconds
[kaboom@thing2 linux]$ ./lat_proc fork
Process fork+exit: 568.0000 microseconds
[kaboom@thing2 linux]$ exit
Script done on Tue Jun 19 17:49:46 2001

Script started on Tue 19 Jun 2001 05:51:38 PM MDT
[kaboom@thing1 solaris]$ ./lat_proc fork
Process fork+exit: 4249.5000 microseconds
[kaboom@thing1 solaris]$ ./lat_proc fork
Process fork+exit: 4212.5000 microseconds
[kaboom@thing1 solaris]$ ./lat_proc fork
Process fork+exit: 4241.0000 microseconds
[kaboom@thing1 solaris]$ exit
script done on Tue 19 Jun 2001 05:52:19 PM MDT

thing1 and thing2 are identical Sun Blade 100s.  thing1 is running Solaris 8
(04/01 release), while thing2 is running 2.4.4 (Debian/unstable).

later,
chris

-- 
Chris Ricker                                               kaboom@gatech.edu
                                                          chris@gurulabs.com

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jonathan Lundell]

At 2:15 PM -0700 2001-06-19, David S. Miller wrote:
>Jonathan Lundell writes:
>  > It seems to me that the telling argument against threads has much
>  > more to do with the potential complexity of the resulting code than
>  > with after-all-minor performance considerations.
>
>I don't get this impression, see the stack space memory usage parts
>of this thread, particular some of Larry's postings.

OK, in some contexts, sure. Larry wrote, for example:

>  ...  It was originally said to some GUI people
>  who wanted to use a thread per object, every button, scrollbar, canvas,
>  text widget, menu, etc., are all threads.  What they didn't figure out is
>  that a thread needs a stack, the stack is the dominating space term, and
>  they were looking at a typical desktop with around 9,000 objects.  Times,
>  at that point, an 8K stack.  That was 73MB in stacks.  Pretty darned stupid
>  when you look at it that way, huh?

But so what? That's $16 worth of DRAM (I just checked). Not so bad 
*if* threads are otherwise a great solution. I grant that one might 
have a pretty tough time making the case, but again, for the right 
application, say some app with a dedicated server, 73MB isn't the end 
of the world (though I suppose it was at the time...).

Regardless, these discussions tend to end up sounding like (in this 
case) "use threads for everything" vs "never ever use threads", 
neither of which is likely to fairly represent the views of the 
participants. Threads have their place, they can be misused, and 
overusing resources is only one of the possible ways to misuse them.
-- 
/Jonathan Lundell.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Timur Tabi]

** Reply to message from Rob Landley <landley@webofficenow.com> on Tue, 19 Jun
2001 14:18:03 -0400


> 2) Not only did Linux not have threads (at all), it didn't plan to have 
> threads, and anybody who brought up the idea of threads was dismissed.  
> Considering this was long before clone, and SMP hardware was starting to come 
> into the high and and looked like it might wind up on the desktop eventually 
> (who knew MS would keep DOS around another ten years, unable to understand 
> two processors, to displays, two mice, two keyboards, and barely able to cope 
> with two hard drives under a 26 letter limit...)

Amen.  This is one of the reasons why I also prefer OS/2 over Linux.

> So I wound up work at IBM doing OS/2 development for a couple years.  On a 
> project called Feature Install, which was based on a subclassed folder in the 
> workplace shell (object oriented desktop).

[snip]

> When they made up a test object hierarchy 
> for all the components of the entire OS, it created so many threads the 
> system ran out and got completely hosed.  I had a command line window open, 
> but couldn't RUN anything, since anything it tried to spawn required a thread 
> to run.  (Child of the shell.)

Feature Installer is a bad example.  That software is a piece of crap for lots
of reasons, excessive threading being only one, and every OS/2 user knew it the
day it was released.  Why do you think WarpIN was created?  

> Sometimes they're an easy way to get asynchronous behavior, and to perform 
> work in the background without the GUI being locked up.  But the difference 
> between "processes" and "threads" there is academic.  Processes with shared 
> memory and some variant of semaphores to avoid killing each other in it.  
> Same thing.

Not quite.  What makes OS/2's threads superior is that the OS multitasks
threads, not processes.  So I can create a time-critical thread in my process,
and it will have priority over ALL threads in ALL processes.

A lot of OS/2 software is written with this feature in mind.  I know of one
programmer who absolutely hates Linux because it's just too difficult porting
software to it, and the lack of decent thread support is part of the problem.

> Bondage and discipline languages that enforce somebody's idea of good 
> programming practice usually just result in WORSE bad programs, and fewer 
> good programs written by people who know how to play with fire without 
> burning themselves.  Saying you can't have threads because they can be 
> misused and "you shouldn't program that way" would be truly dumb.  (Turned ME 
> off for a couple years, anyway.)

Exactly.  Saying that threads cause bad code is just as dumb as saying that a
kernel debugger will cause bad code because programmers will start using the
debugger instead of proper design.

Oh wait, never mind .....


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: Alan Cox quote? (was: Re: accounting for threads)

[David S. Miller]

Jonathan Lundell writes:
 > It seems to me that the telling argument against threads has much 
 > more to do with the potential complexity of the resulting code than 
 > with after-all-minor performance considerations.

I don't get this impression, see the stack space memory usage parts
of this thread, particular some of Larry's postings.

Later,
David S. Miller
davem@redhat.com

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jonathan Lundell]

At 1:57 PM -0700 2001-06-19, David S. Miller wrote:
>So my basic point is that I don't want people to read what you said
>and believe "oh then the difference between threads vs. different
>processes under Solaris is due to Sparc hw architecture reasons
>instead of sw reasons" which simply isn't true.

Yeah, my observation wasn't central to the discussion, and the 
overhead of SPARC register windows is probably more relevant to 
user-level threads, not to mention small compared to IO.

It seems to me that the telling argument against threads has much 
more to do with the potential complexity of the resulting code than 
with after-all-minor performance considerations. If threads truly 
gave one an elegant, fool-proof way to implement otherwise complex 
applications, well, what are MIPS for, anyway?

I have a question, though. The SGI "state threads" mentioned earlier 
use threads in a controlled way with a state-machine programming 
model, which among other things has the potential to take advantage 
of multiple processors. How does one otherwise take advantage of MP 
with a state machine? Multiple processes and shared memory?


-- 
/Jonathan Lundell.

Re: Alan Cox quote? (was: Re: accounting for threads)

[David S. Miller]

Jonathan Lundell writes:
 > Sun (or at least SPARC) is a bit of a special case, though. SPARC's 
 > register-window architecture makes thread-switching (not to mention 
 > recursion) significantly more expensive than on most other 
 > architectures.

The register window flush is a relatively constant cost with a fixed
upper bound, regardless of whether you are switching threads or
processes, the process is the same.

This cost is honestly lost in the noise during a context switch.  The
trap entry/exit in and out of userspace usually costs more cycles than
the window flush at schedule() time.

The worst case whole window flush to the stack can fit (several times
over) in the store cache of UltraSPARC-III.

So my basic point is that I don't want people to read what you said
and believe "oh then the difference between threads vs. different
processes under Solaris is due to Sparc hw architecture reasons
instead of sw reasons" which simply isn't true.

<axe_grind>
Solaris just simply bites it at context switching threads in the
kernel.
</axe_grind>

The same identical code flushes the register windows for processes and
threads under Linux, and there is no reason this should not be the
case.

<axe_grind>

Don't believe me that Solaris sucks here?  Run this experiment under
Solaris-latest and Linux on a sparc64 system (using lmbench):

Under Solaris: ./lat_proc fork
Under Linux: strace -f ./lat_proc fork

I bet the Linux case does better than the Solaris run by some orders
of magnitude.  That's how poor their fork/exit/switch code is.

</axe_grind>

Later,
David S. Miller
davem@redhat.com

Re: Alan Cox quote? (was: Re: accounting for threads)

[Michael Meissner]

On Tue, Jun 19, 2001 at 03:38:34PM -0400, Georg Nikodym wrote:
> >>>>> "GN" == Georg Nikodym <georgn@somanetworks.com> writes:
> 
> >>>>> "MC" == Mike Castle <dalgoda@ix.netcom.com> writes:
>  MC> What about the "UNIX is starting to smell bad" comment?  :->
> 
>  GN> I believe that it comes from a paper that Pike presented at a
>  GN> OSDI (or the Usenix general) last year on the theme of OS
>  GN> Research being dead.  Links to it were also posted on /. around
>  GN> that time...
> 
> Oops.  I was wrong.  I found the presentation I was referring to and
> it doesn't have this quote.

Ummm, the quote about "UNIX is starting to smell bad" is much, much older.  I
think I first heard in the 1989 Baltimore USENIX, when Pike was the featured
speaker, and his talk was "Why workstations don't work", where he outlined
Plan9.  If it wasn't the Baltimore USENIX, it may have been Salt Lake city,
Dallas, or the Boston one.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alexander Viro]

On Tue, 19 Jun 2001, Alan Cox wrote:

> There I disagree. Threads introduce parallelism that the majority of user
> space programmers have trouble getting right (not that C is helpful here).

s/user space//

> A threaded program has a set of extremely complex hard to repeat timing based
> behaviour dependancies. An unthreaded app almost always does the same thing on
> the same input. From a verification and coverage point of view that is 
> incredibly important.

	Exactly. And that's one of the reasons why event-drivel stuff tends to
be buggy. In that respect AIO is not going to be much better than threads.

	BTW, threads of execution don't have to share memory to give an
opportunity of screwup. Lovely example:

	pid = fork():
	if (!pid) {
		while(1) {
			long tmp = lseek(fd, 0, SEEK_CUR);
			long len = lseek(fd, 0, SEEK_END);
			lseek(fd, tmp, SEEK_SET);
			if (!foo(len))
				exit(0);
			sleep(1);
		}
	}
	/* write a lot of stuff to fd */

That, BTW, is pretty close to the GUI braindamage Larry had refered to -
helper process implemented a progress bar.

_Extremely_ nasty data corruption - if child loses timeslice between
the first and third lseeks and parent happens to get that timeslice and
write next chunk...  Happy, happy, joy, joy - child will put the IO pointer
back to the place where it used to be and the next chunk will merrily
overwrite the thing.  Real fun to debug - the thing happens rarely (normally
child has rather high priority after voluntary sleep) and corruption has
a good chance to be confused for an OS bug. Especially if box with OS foo
had demonstrated that behaviour couple of times and box with OS bar either
hadn't done that so far, or corruption hadn't been noticed.

And yes, it's a real-world example - been there, LARTed the idiot who had
written that crap.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Georg Nikodym]

>>>>> "GN" == Georg Nikodym <georgn@somanetworks.com> writes:

>>>>> "MC" == Mike Castle <dalgoda@ix.netcom.com> writes:
 MC> What about the "UNIX is starting to smell bad" comment?  :->

 GN> I believe that it comes from a paper that Pike presented at a
 GN> OSDI (or the Usenix general) last year on the theme of OS
 GN> Research being dead.  Links to it were also posted on /. around
 GN> that time...

Oops.  I was wrong.  I found the presentation I was referring to and
it doesn't have this quote.

Sorry, I'll get my pattern matching unit looked at pronto.

Re: Alan Cox quote? (was: Re: accounting for threads)

[bert hubert]

On Tue, Jun 19, 2001 at 08:18:59PM +0100, Alan Cox wrote:

> > But that foregoes the point that the code is far more complex and harder to
> > make 'obviously correct', a concept that *does* translate well to userspace.
> 
> There I disagree. Threads introduce parallelism that the majority of user
> space programmers have trouble getting right (not that C is helpful here).

True. Balancing with what Larry said, threads require education. In good
Unix tradition you can shoot yourself in the foot in many ways. 

> A threaded program has a set of extremely complex hard to repeat timing based
> behaviour dependancies. An unthreaded app almost always does the same thing on
> the same input. From a verification and coverage point of view that is 
> incredibly important.

Reproducability is very important. But where threads may become inefficient
if used unwisely (I handily do many megabits of DNS traffic with our
threaded daemon by the way), statemachines have a way if becoming very
intractable - leading to whole new problems.

It's an 'enough rope' thing. Bad programmers will always write broken code -
the saving grace of state machines are that they are hard to write, which
means that *if* they are being used, it is often by a skilled programmer.

Regards,

bert

-- 
http://www.PowerDNS.com      Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alan Cox]

> Which clearly marks you as a typical kernel-side developer :-) It never
> ceases to amaze me how different a userland perspective can be from that of
> people who live in kernel space.

I've been writing multiuser games since 1987. I'm not just a kernel hacker

> But that foregoes the point that the code is far more complex and harder to
> make 'obviously correct', a concept that *does* translate well to userspace.

There I disagree. Threads introduce parallelism that the majority of user
space programmers have trouble getting right (not that C is helpful here).

A threaded program has a set of extremely complex hard to repeat timing based
behaviour dependancies. An unthreaded app almost always does the same thing on
the same input. From a verification and coverage point of view that is 
incredibly important.

Alan

Re: Alan Cox quote? (was: Re: accounting for threads)

[bert hubert]

On Tue, Jun 19, 2001 at 09:02:16AM -0700, David S. Miller wrote:
> 
> Dan Kegel writes:
>  > Alan, did you really say that, or are people taking your name in vain?
> 
> He did say it, and I for one agree with him. :-)

Which clearly marks you as a typical kernel-side developer :-) It never
ceases to amaze me how different a userland perspective can be from that of
people who live in kernel space.

You could write 'how many kernel developers does it take to screw in a
lightbulb'-type jokes I suspect. Except that sometimes it isn't funny

Alan may be right in stating that nothing beats userspace state machines in
the same number of processes as there are cpus, from an efficiency
standpoint.

But that foregoes the point that the code is far more complex and harder to
make 'obviously correct', a concept that *does* translate well to userspace.

Regards,

bert hubert

-- 
http://www.PowerDNS.com      Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

Re: Alan Cox quote? (was: Re: accounting for threads)

[Alan Cox]

> How about "If you think you need threads, stop programming with closed
> sourced libraries where the documentation doesn't give you a clue how
> you might make things work within a state machine way"

Linux inherits several unix properties which are not friendly to good state
based programming - lack of good AIO for one.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley]

On Tuesday 19 June 2001 12:52, Larry McVoy wrote:
> On Tue, Jun 19, 2001 at 05:26:09PM +0100, Matthew Kirkwood wrote:
> > On Tue, 19 Jun 2001, Larry McVoy wrote:
> > >     ``Think of it this way: threads are like salt, not like pasta. You
> > >     like salt, I like salt, we all like salt. But we eat more pasta.''
> >
> > This is oft-quoted but has, IMO, the property of not actually
> > making any sense.
>
> Hmm.  Makes sense to me.  All it is saying is that you can't make a good
> dinner out of a pile of salt.  It was originally said to some GUI people
> who wanted to use a thread per object, every button, scrollbar, canvas,
> text widget, menu, etc., are all threads.  What they didn't figure out is
> that a thread needs a stack, the stack is the dominating space term, and
> they were looking at a typical desktop with around 9,000 objects.  Times,
> at that point, an 8K stack.  That was 73MB in stacks.  Pretty darned stupid
> when you look at it that way, huh?

I've seen worse.

Back around '93 or so I took a look at Linux and wound up putting OS/2 on my 
desktop instead of Linux for 2 reasons.

1) Diamond Stealth video card.  It worked in OS/2, didn't work in Linux, and 
the reason was you guys couldn't get vendor support while IBM could.  
According to this list, it was entirely possible this sort of problem would 
NEVER be addressed.  (We got around it with reverse engineering and critical 
mass, but at the time hardware was changing way faster than we could keep up 
with it.)

2) Not only did Linux not have threads (at all), it didn't plan to have 
threads, and anybody who brought up the idea of threads was dismissed.  
Considering this was long before clone, and SMP hardware was starting to come 
into the high and and looked like it might wind up on the desktop eventually 
(who knew MS would keep DOS around another ten years, unable to understand 
two processors, to displays, two mice, two keyboards, and barely able to cope 
with two hard drives under a 26 letter limit...)

So I wound up work at IBM doing OS/2 development for a couple years.  On a 
project called Feature Install, which was based on a subclassed folder in the 
workplace shell (object oriented desktop).  The idea was you fill up a folder 
with files, drag and drop them from diskette to desktop, and they install 
themselves automatically.  (Went out the window when a single install object 
had to span two disks, but oh well.  By then, they were stuck with the 
design.  I inherited it after a year or two of scar tissue had accumulated.)

They created THREE threads for every single object, and they objects could 
nest arbitrarily deep.  (Modular installs with sub-components.)  The OS had a 
default of 1024 threads (expandable to 4096, I believe, before they hit a 64k 
limit somewhere in the coding).  When they made up a test object hierarchy 
for all the components of the entire OS, it created so many threads the 
system ran out and got completely hosed.  I had a command line window open, 
but couldn't RUN anything, since anything it tried to spawn required a thread 
to run.  (Child of the shell.)

One three finger salute later, the desktop comes back up automatically, with 
this nasty tangle of objects STILL there, and of course hoses itself AGAIN as 
the desktop instantiates all those objects in memory with their three threads 
apiece, and runs out again...

Those were the days.  If I remember correctly, I replace ALL those threads 
with a single thread doing all the work, a mutex protected linked list of 
work to do, and an event semaphore to tell it to do it.

> Nobody is arguing that having more than one thread of execution in an
> application is a bad idea.  On an SMP machine, having the same number of
> processes/threads as there are CPUs is a requirement to get the scaling
> if that app is all you are running.  That's fine.  But on a uniprocessor,
> threads are basically stupid.

Sometimes they're an easy way to get asynchronous behavior, and to perform 
work in the background without the GUI being locked up.  But the difference 
between "processes" and "threads" there is academic.  Processes with shared 
memory and some variant of semaphores to avoid killing each other in it.  
Same thing.

And I think the most I've ever REALLY used is about three for a whole 
program.  (Unless you're talking about a server with a thread pool handling 
connections.  And yeah that could be done with poll and non-blocking I/O, but 
not if you're shelling out to ssh and such...)

>  The only place that I know of where it is
> necessary is for I/O which blocks.  And even there you only need enough
> to overlap the I/O such that it streams.  And processes will, and do,
> work fine for that.

And nonblocking GUI elements, and breaking up work for multiple processors, 
and probably a few other things.

But I think the MAIN difference between the two camps is that the people who 
despise threads consider them to be a lot different from processes, and the 
people who like threads consider it a semantic argument.  I worry about cache 
trashing with too much shared data in an SMP system, but like the fact you 
automatically have synchronization primitives in a threading environment 
which might not be there if you're just dealing with processes.

I've used the filesystem for synchronization.  Back around 1991 I wrote my 
own fidonet compatable multinode BBS under DOS with desqview, including the 
mail tosser, from scratch in Borland C++ with nothing but file locking to 
keep the instances from killing each other, and I got 30 messages/second 
throughput on a 33 mhz 386.  The mail tosser could catch new posts in the 
middle of a stream of incoming messages from the network without ever having 
to look at an individual message message twice, and packed the message bases 
during the act of posting.  (And a bunch of fancy features I won't bore you 
with, especially the way delete worked.)

After doing all that with stone knives and bearskins, I -APPRECIATED- a 32 
bit flat memory model with threads. :)

> I think the general thrust of us ``anti-thread'' people is that a few
> are fine, a lot is stupid, and the model encourages a lot.  It's just
> like perl5, C++, pick-your-favorite-feature-rich-language in that
> exceptional programmers will do a good job with the problem but average
> programmers will do a horrible job.  Given that there are only a few
> exceptional programmers and a never ending wave of average programmers,
> the argument is that one should tailor the paradigm for the common case,
> not for the exceptional case.

There has not been and never will be a language in which it is the least bit 
difficult to write bad programs.

I don't remember who said that, but it should be on your list.  (Ask Nancy 
Lebowitz.)

Bondage and discipline languages that enforce somebody's idea of good 
programming practice usually just result in WORSE bad programs, and fewer 
good programs written by people who know how to play with fire without 
burning themselves.  Saying you can't have threads because they can be 
misused and "you shouldn't program that way" would be truly dumb.  (Turned ME 
off for a couple years, anyway.)

Rob

Re: Alan Cox quote? (was: Re: accounting for threads)

[Georg Nikodym]

>>>>> "MC" == Mike Castle <dalgoda@ix.netcom.com> writes:

 MC> What about the "UNIX is starting to smell bad" comment?  :->

I believe that it comes from a paper that Pike presented at a OSDI (or
the Usenix general) last year on the theme of OS Research being dead.
Links to it were also posted on /. around that time...

Re: Alan Cox quote? (was: Re: accounting for threads)

[Steve Underwood]

Larry McVoy wrote:
> 
> On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote:
> > On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote:
> > > Another one that I can't believe I forgot is from Rob Pike:
> > >
> > >     "If you think you need threads then your processes are too fat"
> >
> > Also, I could never actually find the "too fat" quote anywhere.
> 
> I can personally vouch for the too fat comment, I've heard him say it in
> person.

How about "If you think you need threads, stop programming with closed
sourced libraries where the documentation doesn't give you a clue how
you might make things work within a state machine way"

Regards,
Steve

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mike Castle]

On Tue, Jun 19, 2001 at 10:37:12AM -0700, Larry McVoy wrote:
> On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote:
> > Also, I could never actually find the "too fat" quote anywhere.  
> 
> I can personally vouch for the too fat comment, I've heard him say it in
> person.

What about the "UNIX is starting to smell bad" comment?  :->

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 10:36:00AM -0700, Jonathan Lundell wrote:
> At 9:09 AM -0700 2001-06-19, Larry McVoy wrote:
> >Don't you think it is funny that Sun doesn't publish numbers comparing
> >their thread performance to process performance?  Sure, you can find
> >context switch benchmarks where they have user level switching going on
> >but those are a red herring.  The real numbers you want are the kernel
> >level context switches and those are just as expensive as the process
> >context switch numbers.
> 
> Sun (or at least SPARC) is a bit of a special case, though. SPARC's 
> register-window architecture makes thread-switching (not to mention 
> recursion) significantly more expensive than on most other 
> architectures.

Yes, but that misses the point.  The point is that you have to do the same
work, almost, to switch a kernel thread as a process.  You don't have to
switch the VM context but that isn't the dominating term.  So the fact that
Sun has slow[er] context switching and slow[er] thread switching isn't the
issue.  The issue is that people perceive threads to be cheap but they are
not cheap at all.  It's the relative cheapness, or lack thereof, when 
comparing them to processes.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote:
> On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote:
> > Another one that I can't believe I forgot is from Rob Pike:
> > 
> >     "If you think you need threads then your processes are too fat"
> 
> Also, I could never actually find the "too fat" quote anywhere.  

I can personally vouch for the too fat comment, I've heard him say it in
person.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Jonathan Lundell]

At 9:09 AM -0700 2001-06-19, Larry McVoy wrote:
>Don't you think it is funny that Sun doesn't publish numbers comparing
>their thread performance to process performance?  Sure, you can find
>context switch benchmarks where they have user level switching going on
>but those are a red herring.  The real numbers you want are the kernel
>level context switches and those are just as expensive as the process
>context switch numbers.

Sun (or at least SPARC) is a bit of a special case, though. SPARC's 
register-window architecture makes thread-switching (not to mention 
recursion) significantly more expensive than on most other 
architectures.
-- 
/Jonathan Lundell.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Mike Castle]

On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote:
> Another one that I can't believe I forgot is from Rob Pike:
> 
>     "If you think you need threads then your processes are too fat"

Pike also to have said, "Not only is UNIX dead, it's starting to smell bad."

Also, I could never actually find the "too fat" quote anywhere.  Best I
could find was one of Pike's papers on the plan9 site.  Best that I can
tell is that both of these quotes are Urban Legends.

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Alan Cox quote? (was: Re: accounting for threads)

[Matti Aarnio]

  I can understand the opinnions expressed by these quotes.
  Having seen how horribly certain CORBA monsters work, I am sure
  that the basic idea of threads is lost somewhere along the way...

On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote:
> > > >--
> > > > "A Computer is a state machine.
> > > >  Threads are for people who can't program state machines."
> > > >       - Alan Cox
.... 
> And one from me:
> 
>     ``Think of it this way: threads are like salt, not like pasta. You
>     like salt, I like salt, we all like salt. But we eat more pasta.''
> 
> Threads are a really bad idea.  All you need are processes and either the
> ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good
> old mmap(2).  If you allow threads then all you are saying is that your
> process model is so pathetic you had to invent another, supposedly lighter
> weight, object to do the same thing.  

   That is usually true.   In rare cases I *do* want to use threads, or
   things just alike them.

   Pre-requisite are for wanting to share very large amounts of the VM
   of the processes and/or IO descriptors, have multiple processors in
   the system capable to execute my code, and wanting to parallellize
   (with lack of AIO) certain IO activities (disk related, mainly) which
   normal non-blocking IO can't handle.


   Threads are like salt, best used in moderation.
   They are resources, and hogging them will very rapidly cause
   the harms to exceed the benefits.


   (...that CORBA beast...)  ... creates a thread for each incoming
   request without any sort of limit at how much there can be threads
   running in parallel.

> Don't you think it is funny that Sun doesn't publish numbers comparing
> their thread performance to process performance?  Sure, you can find 
> context switch benchmarks where they have user level switching going on
> but those are a red herring.  The real numbers you want are the kernel
> level context switches and those are just as expensive as the process
> context switch numbers.

   If they weren't, I would be most amazed..

> -- 
> Larry McVoy   	 lm at bitmover.com         http://www.bitmover.com/lm 

/Matti Aarnio

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 05:26:09PM +0100, Matthew Kirkwood wrote:
> On Tue, 19 Jun 2001, Larry McVoy wrote:
> 
> >     ``Think of it this way: threads are like salt, not like pasta. You
> >     like salt, I like salt, we all like salt. But we eat more pasta.''
> 
> This is oft-quoted but has, IMO, the property of not actually
> making any sense.

Hmm.  Makes sense to me.  All it is saying is that you can't make a good
dinner out of a pile of salt.  It was originally said to some GUI people
who wanted to use a thread per object, every button, scrollbar, canvas,
text widget, menu, etc., are all threads.  What they didn't figure out is
that a thread needs a stack, the stack is the dominating space term, and
they were looking at a typical desktop with around 9,000 objects.  Times,
at that point, an 8K stack.  That was 73MB in stacks.  Pretty darned stupid
when you look at it that way, huh?

Nobody is arguing that having more than one thread of execution in an
application is a bad idea.  On an SMP machine, having the same number of
processes/threads as there are CPUs is a requirement to get the scaling
if that app is all you are running.  That's fine.  But on a uniprocessor,
threads are basically stupid.  The only place that I know of where it is
necessary is for I/O which blocks.  And even there you only need enough
to overlap the I/O such that it streams.  And processes will, and do,
work fine for that.

I think the general thrust of us ``anti-thread'' people is that a few
are fine, a lot is stupid, and the model encourages a lot.  It's just
like perl5, C++, pick-your-favorite-feature-rich-language in that
exceptional programmers will do a good job with the problem but average
programmers will do a horrible job.  Given that there are only a few
exceptional programmers and a never ending wave of average programmers,
the argument is that one should tailor the paradigm for the common case,
not for the exceptional case.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Matthew Kirkwood]

On Tue, 19 Jun 2001, Larry McVoy wrote:

>     ``Think of it this way: threads are like salt, not like pasta. You
>     like salt, I like salt, we all like salt. But we eat more pasta.''

This is oft-quoted but has, IMO, the property of not actually
making any sense.

Besides, it offers the unhealthy among us an excuse for bad
design.

Matthew.

Re: Alan Cox quote? (was: Re: accounting for threads)

[Padraig Brady]

We'll yes it's true you can program everything
like a state machine if the correct OS interfaces are
there. I don't think they are though ATM. Also
some things are more elegantly implemented using
threads, whereas others are better as state machines.

Padraig.

David S. Miller wrote:

>Dan Kegel writes:
> > Alan, did you really say that, or are people taking your name in vain?
>
>He did say it, and I for one agree with him. :-)
>
>Later,
>David S. Miller
>davem@redhat.com
>

Re: Alan Cox quote? (was: Re: accounting for threads)

[Larry McVoy]

On Tue, Jun 19, 2001 at 08:58:20AM -0700, Dan Kegel wrote:
> ognen@gene.pbi.nrc.ca wrote:
> > 
> > On an unrelated note:
> > 
> > I noticed the quote below in your message. Is this a true quote or just a
> > joke going around? I have tried believing it is just a joke but I am
> > scared it is not.
> > 
> > >--
> > > "A Computer is a state machine.
> > >  Threads are for people who can't program state machines."
> > >       - Alan Cox
> 
> Alan, did you really say that, or are people taking your name in vain?

Yup Alan said and I liked it so much I put it on my quotes page,
http://www.bitmover.com/lm/quotes.html

Another one that I can't believe I forgot is from Rob Pike:

    "If you think you need threads then your processes are too fat"

And one from me:

    ``Think of it this way: threads are like salt, not like pasta. You
    like salt, I like salt, we all like salt. But we eat more pasta.''

Threads are a really bad idea.  All you need are processes and either the
ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good
old mmap(2).  If you allow threads then all you are saying is that your
process model is so pathetic you had to invent another, supposedly lighter
weight, object to do the same thing.  

Don't you think it is funny that Sun doesn't publish numbers comparing
their thread performance to process performance?  Sure, you can find 
context switch benchmarks where they have user level switching going on
but those are a red herring.  The real numbers you want are the kernel
level context switches and those are just as expensive as the process
context switch numbers.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Alan Cox quote? (was: Re: accounting for threads)

[Ben Pfaff]

Dan Kegel <dank@kegel.com> writes:

> ognen@gene.pbi.nrc.ca wrote:
> > 
> > On an unrelated note:
> > 
> > I noticed the quote below in your message. Is this a true quote or just a
> > joke going around? I have tried believing it is just a joke but I am
> > scared it is not.
> > 
> > >--
> > > "A Computer is a state machine.
> > >  Threads are for people who can't program state machines."
> > >       - Alan Cox
> 
> Alan, did you really say that, or are people taking your name in vain?

Actually he left out the apostrophe and didn't capitalize
`computer'.  See, e.g., 
	http://www.google.com/search?q=cache:myb1i-ixJ0k:web.gnu.walfield.org/mail-archive/linux-kernel/2000-January/3533.html
-- 
"...dans ce pays-ci il est bon de tuer de temps en temps un amiral
 pour encourager les autres."
--Voltaire, _Candide_

Re: Alan Cox quote? (was: Re: accounting for threads)

[David S. Miller]

Dan Kegel writes:
 > Alan, did you really say that, or are people taking your name in vain?

He did say it, and I for one agree with him. :-)

Later,
David S. Miller
davem@redhat.com

Alan Cox quote? (was: Re: accounting for threads)

[Dan Kegel]

ognen@gene.pbi.nrc.ca wrote:
> 
> On an unrelated note:
> 
> I noticed the quote below in your message. Is this a true quote or just a
> joke going around? I have tried believing it is just a joke but I am
> scared it is not.
> 
> >--
> > "A Computer is a state machine.
> >  Threads are for people who can't program state machines."
> >       - Alan Cox

Alan, did you really say that, or are people taking your name in vain?

- Dan