Re: revivesa status 2008/07/09

[SODA Noriyuki <soda%sra.co.jp@localhost>]

>>>>> On Fri, 25 Jul 2008 07:40:01 +0000, Andrew Doran 
>>>>> <ad%netbsd.org@localhost> said:

>> I disagree, because:
>> 
>> 1) It makes hard to use alternate pthread library, especially pthread
>> libraries which support more than 100,000 threads.
>> With today's RAM price, such number of threads can be easily
>> supported by userland implementations and SA pthread, but
>> current 1:1 thread library just cannot support such application.

> There is a fixed artificial limit in the kernel for 1:1 threads for a simple
> reason: there is no other limiting mechanism. That should be made a tuneable.

It's tunable, but it is not able to deal with 100,000 threads, is it?

> Note that the SA pthread library has a large locked memory footprint for
> upcall stacks. It typically uses more wired memory than 1:1, however kernel
> VA usage is a problem for 1:1.

That's not problem at all, because the number of upcalls are
negligible in this application.
Very few threads are doing I/O.

> If you want 100,000 threads in a single process, running inside a single
> metal box, I think there is something dramatically wrong with your
> application,

It's not wrong.

As I said earlier, using one thread per object makes programming a lot
easier in some applications.
UNIX pipeline is one of such applications.

Do you think the programming model of UNIX pipeline is dramatically
wrong?
I don't think so.

Of course, UNIX pipeline is NOT most efficient way to solve problem
from computer cycle view point.  But it's indeed efficient way
from human resource view point, because it's really easy to program.
All of us know that, don't you?

> but you can have them with 1:1 by using a 64-bit system.

How much RAM is necessary?
Does current netbsd 1:1 thread really can cope with it?

> Finally, note that our 1:1 thread library is probably capable of creating
> your 100k threads in under a second, which is more than can be said for
> competing systems.

I think you are just wrong in this point.
Userland pthread implementation can create 100k thread without
any userland-kernel context switch.
That is impossible in 1:1 implementation at all.

>> 2) This is not what most other UNIX-based OSes do.
>> Solaris, HP-UX, Linux and FreeBSD are all use indepedent libpthread
>> library.  Making NetBSD different from UNIX common sense is not
>> way to go.

> From Solaris 10 onwards threading is integrated into libc.

OK.
But HP-UX, Linux and FreeBSD are all still using seperate pthread
library.
And 1) is a still critical problem.
-- 
soda