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.
> Bu
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
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
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
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
> 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 Ma
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 oth
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
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 for
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 INTEN
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
> d
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
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
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
> > 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, ex
Alexander Viro <[EMAIL PROTECTED]> 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.
> Well, if you use GFP_ATOMIC for everything... grep..
Rok papez <[EMAIL PROTECTED]> 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.''
> H
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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the
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.
> Well, if you use GFP_ATOMIC for everything..
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.
Well, if you use GFP_ATOMIC for everything... grep...
Erm... AFAICS, you call create_chain() with interrupts
In message <[EMAIL PROTECTED]> 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
On Wednesday 20 June 2001 21:57, D. Stimits wrote:
> 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
On Thursday 21 June 2001 10:02, Jesse Pollard wrote:
> Rob Landley <[EMAIL PROTECTED]>:
> > 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 an
Rob Landley <[EMAIL PROTECTED]>:
>
> 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 ad
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
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 wo
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
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
export IFS=$'\n'
> lines=`ls -l | awk '{print "\""$0"\""}'`
> for i in $lines
> do
> echo line:$i
> done
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
P
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
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'
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.
} --
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 Mc
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 threa
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 arou
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
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
> "Al" == Alexander Viro <[EMAIL PROTECTED]> 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 co
> 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
> "Alan" == Alan Cox <[EMAIL PROTECTED]> 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
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 exa
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 thi
> 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
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
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()
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
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 [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
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,
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
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 so
On Tue, 19 Jun 2001, David S. Miller wrote:
>
>
> 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
** Reply to message from Rob Landley <[EMAIL PROTECTED]> 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 hard
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
On Tue, Jun 19, 2001 at 03:38:34PM -0400, Georg Nikodym wrote:
> > "GN" == Georg Nikodym <[EMAIL PROTECTED]> writes:
>
> > "MC" == Mike Castle <[EMAIL PROTECTED]> writes:
> MC> What about the "UNIX is starting to smell bad" comment? :->
>
> GN> I believe that it comes from a paper tha
> 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 fr
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
> "GN" == Georg Nikodym <[EMAIL PROTECTED]> writes:
> "MC" == Mike Castle <[EMAIL PROTECTED]> 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 th
> 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
> 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 -
> "MC" == Mike Castle <[EMAIL PROTECTED]> 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 /.
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"
>
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
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 t
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
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
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 act
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 m
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,
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 w
On Tue, Jun 19, 2001 at 08:58:20AM -0700, Dan Kegel wrote:
> [EMAIL PROTECTED] 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.
> >
Dan Kegel <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] 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 C
[EMAIL PROTECTED] 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
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.
Best regards,
Ognen
On Tue, 19 Jun 2001, Dan Kegel wrote:
[reply snipped]
>
>--
> "A Computer is a state machi
Hi.
First, sorry if this is a glibc issue. Just chose to ask here first.
I want to know the CPU time used by a POSIX-threaded program. I have tried
to use getrusage() with RUSAGE_SELF and RUSAGE_CHILDREN. Problem:
main thread just do nothing, spawns children and waits. And I get always
0 ru_utim
74 matches
Mail list logo
