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.
>
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
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
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?
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
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
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
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
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
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
>
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.
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 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
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
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
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 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
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
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
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 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
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
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,
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...
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. looking through the thing raised brows
Well, if you use
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
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
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.''
>
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
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
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
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
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
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
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 added some kind of
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 and don't group
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
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 so far
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
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
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.''
Here are
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 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
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
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
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
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
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
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
>
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
> "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
> 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
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
> 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
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
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
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
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
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
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
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
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
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.
}
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
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
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
Please read
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
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
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 user space
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
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 core
dump and
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
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.
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
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
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
> 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
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
> "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
> 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
> 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
1 - 100 of 146 matches
Mail list logo
