Dimitris Vyzovitis wrote:
> Nathan Meyers wrote:
>
> > But I'm always curious about "wacky people" who like to
> > use thousands of threads (or tons of memory or zillions of levels of
> > recursion, etc.). Is that approach fundamental to solving the problem
> > efficiently, or do you use it becau
Dimitris Vyzovitis wrote:
> Nathan Meyers wrote:
>
> > But I'm always curious about "wacky people" who like to
> > use thousands of threads (or tons of memory or zillions of levels of
> > recursion, etc.). Is that approach fundamental to solving the problem
> > efficiently, or do you use it becau
> Nelson Minar writes:
Nelson> I'm curious how Java thread priorities are layered on top
Nelson> of LinuxThreads.. When a thread of high priority becomes
Nelson> runnable, is a SIGSTOP sent to all lower priority threads
Nelson> to make them stop until the high priority thread
Nathan Meyers wrote:
> But I'm always curious about "wacky people" who like to
> use thousands of threads (or tons of memory or zillions of levels of
> recursion, etc.). Is that approach fundamental to solving the problem
> efficiently, or do you use it because it's convenient and/or cool?
>
Som
At 12:09 PM -0500 2/8/99, Nelson Minar wrote:
>A bit more info on thread limits.. Linux 2.0 defines NR_TASKS in
>/usr/src/linux/include/linux/tasks.h. The default is 512, but then
>there's MAX_TASKS_PER_USER which is defined as NR_TASKS/2. So if I
>understand right, that means that a Java process
Nathan Meyers asks:
>But I'm always curious about "wacky people" who like to use thousands
>of threads (or tons of memory or zillions of levels of recursion,
>etc.). Is that approach fundamental to solving the problem
>efficiently, or do you use it because it's convenient and/or cool?
A bit of bo
A bit more info on thread limits.. Linux 2.0 defines NR_TASKS in
/usr/src/linux/include/linux/tasks.h. The default is 512, but then
there's MAX_TASKS_PER_USER which is defined as NR_TASKS/2. So if I
understand right, that means that a Java process using native threads
is limited to 256 threads in
Nathan Meyers wrote,
> But I'm always curious about "wacky people" who like
> to use thousands of threads (or tons of memory or
> zillions of levels of recursion, etc.). Is that
> approach fundamental to solving the problem
> efficiently, or do you use it because it's convenient
> and/or cool?
Er
Nelson Minar wrote:
>
> >All that other discussion about Linux process table slots and
> >implementation details is interesting, but not really relevant to the
> >distinction between light and heavy.
>
> There's one important difference - you can only have as many threads
> in Linux as you can h
Michael Sinz wrote:
>
> >Aren't we supposed to be able to overcome this limitation? It is really
> >sad to have this limitation hanging as a big dark cloud above us. ;-}
> >I believe that this limitation is not the case in some other "massively
> >inferior" OSes like NT. I would also like to aug
Nelson Minar wrote:
> >All that other discussion about Linux process table slots and
> >implementation details is interesting, but not really relevant to the
> >distinction between light and heavy.
>
> There's one important difference - you can only have as many threads
> in Linux as you can have
Nathan Meyers wrote:
>
> I think a lot of people are getting hung up on the notion of lightweight
> vs heavyweight processes. Here's the quick definition of the
> differences, followed by an explanation of why it's not really relevant
> to this discussion:
>
> - Heavyweight processes run in sepa
> There's one important difference - you can only have as many threads
> in Linux as you can have processes. And there's a suprisingly low
> upper limit on that, something like 256? I'm one of those wacky people
> who likes the idea of writing programs with thousands of threads (most
> stopped mo
>All that other discussion about Linux process table slots and
>implementation details is interesting, but not really relevant to the
>distinction between light and heavy.
There's one important difference - you can only have as many threads
in Linux as you can have processes. And there's a supris
David Wall wrote:
>
> >This makes me wonder.
> >AFAIK, according to their definition, threads are supposed to be
> "lightweight"
> >processes.
I think a lot of people are getting hung up on the notion of lightweight
vs heavyweight processes. Here's the quick definition of the
differences, follow
I don't know much about the specifics of linuxthreads, but pthreads are
usually implemented with a group of kernel threads (supplied by clone()
syscall in this case, and they're definitely "light-weight" processes).
Perhaps, they've been referred to as "heavy-weight" just as a term
relative to gre
> Dimitris Vyzovitis writes:
Dimitris> This makes me wonder. AFAIK, according to their
Dimitris> definition, threads are supposed to be "lightweight"
Dimitris> processes. How are linuxthreads actually implemented?
Dimitris> ie, do we get the real lightweight process that we
>This makes me wonder.
>AFAIK, according to their definition, threads are supposed to be
"lightweight"
>processes.
>How are linuxthreads actually implemented? ie, do we get the real
lightweight
>process that we are supposed to get by the pthreads definitions?
>The descriptions seen in the discussi
Gerald Gutierrez wrote:
>
>
> Non-Java processes don't have the problem because "processes" are
> heavyweight native threads, essentially. Non-Java threads MAY have the
> problem if they are not native threads.
>
> Assuming you are talking about Linux when you talk about G++, yes Linux
> implemen
The difference between "green" threads and "native" threads is that in the
latter the operating system provides for thread support while in the former
the application, in this case a JVM, builds its own thread support on top
of one native thread.
Hence, if a JVM's green thread implementation doe
20 matches
Mail list logo
