java version "1.5.0_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03)
Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode)
On a redhat 9 machine, I can get a maximum of 612 threads in tomcat when
I start it with -Xmx1500M. Without a -Xmx param I get 34
hi all
I am working on a project which needs JVM to work without the
support of Operating Systems. The JVM I am working with uses Pthreads of
Linux and hence I am unable to compile it with a arm cross compiler. I
came to know that Green Threads works without the help of Operating System
Hi
I have successfuly folowed your advise. After rekompiling the kernel so that I now can
address 4G of memory, change the max #processes plus changed the thread stacksize i
now can create more than 12 000 threads (which is pretty cool i thing), the limit must
now be the 4G addressspace limit
On Wed, Feb 04, 2004 at 07:06:24PM +0100, Vincent Touquet wrote:
> On Wed, Feb 04, 2004 at 09:56:57AM -0800, Hui Huang wrote:
> >Default stack size is 512k. You need 3500 * 512k = 1750M address space
> >for 3500 threads. Try -Xss96k. Also check your limit on max #processes
>
Vincent Touquet wrote:
On Wed, Feb 04, 2004 at 09:56:57AM -0800, Hui Huang wrote:
Default stack size is 512k. You need 3500 * 512k = 1750M address space
for 3500 threads. Try -Xss96k. Also check your limit on max #processes
(ulimit -u), you can't create more threads than that limit either.
On Wed, Feb 04, 2004 at 09:56:57AM -0800, Hui Huang wrote:
>Default stack size is 512k. You need 3500 * 512k = 1750M address space
>for 3500 threads. Try -Xss96k. Also check your limit on max #processes
>(ulimit -u), you can't create more threads than that limit either.
Is there
Nathan Bryant wrote:
Daniel Malmkvist wrote:
To my supprise i could not have more then ~3500 threads at the same time.
I got a OutOfMemoryException, but there was plenty of system memory left
(the JVM only ha about 10% of system physical memory).
Address space might be a limiting factor in a
Daniel Malmkvist wrote:
To my supprise i could not have more then ~3500 threads at the same time.
I got a OutOfMemoryException, but there was plenty of system memory left
(the JVM only ha about 10% of system physical memory).
Address space might be a limiting factor in a 32-bit machine
Hi
I was making som tests to see the maximum number of threads i could create
with the new linux thread library (NPTL). I had heard foks having up to
100 000 threads at the same time so i wanted to try for my self.
I used the 2.6.1 kernel with glibc with NPTL support, I used Sun JVM
v1.4.2 wich
On Thu, 2003-02-06 at 04:41, Henrique wrote:
> Folks, what's the diference between Native and Green Threads for the
> performance of a software and for System Operation?
Green Threads is linked into the JDK to simulate a threading
environment; it manages all thread creation,
Folks, what's the diference between Native and Green Threads for the
performance of a software and for System Operation?
The new Linux Kernel 2.4.20 manage all threads as Native, but using the
concept of Green?
Regards,
Hen
I just joined the list today so my apologies if this has already been
covered but hasn't made it to the archive yet.
>From lkml: first NPT vs. NGPT vs. LinuxThreads benchmark results at
http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/1581.html
Note as well that there is an NPT mailing list
and reschedule which adds additional overhead that neither
green threads nor FreeBSD's libc_r has. That's going to be a tough
combination to beat and you've got to admit that, right ? ;)
FPU/exception issues might make things more bizzare since architectural specific
details vary ac
w that. What about context switching overhead ? I would
expect a userspace system to still be substantially faster than anything
kernel bound.
> M:N threading systems and userspace threading libraries add a noticable
> amount of complexity, but historically have had a speed advantage over
>
On Wed, Sep 04, 2002 at 07:59:30AM -0700, Dan Kegel wrote:
> As I wrote in a previous message, Sun is abandoning M:N threading;
> see http://java.sun.com/docs/hotspot/threads/threads.html
> NGPT is probably a dead end. I suspect Gnu and Linux will continue
> on with kernel-based
's probably a good thing to get
rid of it. A good M:N threading system should be able to get you green
threads like context switch performance while the IO system is back by
a kernel threading entity...
FreeBSD's libc_r (Posix threading) is basically a kind of green threading
for
I just had a look at the mail-archive of their mailing-list. There is a
statement clarifying, their stuff will NOT work with current JVMs.
Look here:
http://www-124.ibm.com/pipermail/pthreads-users/2002-August/000250.html
It seems also Sun will not support NGPT anytime soon, as they focus on
Cool I'm curious too, as I have
an MP server...
regards
v
On Wed, Sep 04, 2002 at 09:30:33AM +0200, Marco Trevisan wrote:
>Thanks to all you guys! :)
>
>I will try it (most probabily next week) and report back to the mailing
>list.
>The main reasons are:
>1) I would like to deploy on multi-proc
Thanks to all you guys! :)
I will try it (most probabily next week) and report back to the mailing
list.
The main reasons are:
1) I would like to deploy on multi-processor Linux systems without
lacking in scalability;
2) If it works, not only Catalina will benefit from this, but the
overall se
On Tue, Sep 03, 2002 at 10:03:15PM +0200, Marco Trevisan wrote:
> I looked at the NGPT home page, surfed the net and found some
> interesting benchmarks :
> http://www.opengroup.org/rtforum/jan2002/slides/linux/abt.pdf .
>
> At http://www.ibm.com/developerworks/oss/pthreads/, they say: "This
>
On Tue, Sep 03, 2002 at 10:03:15PM +0200, Marco Trevisan wrote:
> I found out that the best performing JVM on a single-processor Linux
> machine is Blackdown-1.3.1 with green threads and the OpenJIT compiler.
> Other JVMs I tried are: IBM v1.3.0 - 1.3.1, Sun v1.3.1 - 1.4.x
If there is
Yup native threads doing blocking IO on linux is expensive. Things start
looking progressively ugly from 50 connections upwards.
If you move to NIO you will see a significant improvement in both
stability/predictability and performance.
What would make it easier for you to try the
best performing JVM on a single-processor Linux
machine is Blackdown-1.3.1 with green threads and the OpenJIT compiler.
Other JVMs I tried are: IBM v1.3.0 - 1.3.1, Sun v1.3.1 - 1.4.x
It was a surprise for me to find out such a result, infact some
benchmark classes I've done in order to me
> "Mauricio" == Mauricio Nuñez <[EMAIL PROTECTED]> writes:
> Thanks for your answers!
> Well, i will need to wait for a back port from kernel 2.5 to 2.4 ...
> I'm trying to get a better performance with Tomcat (a servlet
> container).
> The servlet spec say '1 request: 1 thread', then with
.
Thanks
El mar, 20-08-2002 a las 13:21, Juergen Kreileder escribió:
> Mauricio Nuñez <[EMAIL PROTECTED]> writes:
>
> > Blackdown JVM 1.3 support green and native threads, but 1.4 only
> > native. Threading is an important issue for the server side java
> > applicati
Mauricio Nuñez <[EMAIL PROTECTED]> writes:
> Blackdown JVM 1.3 support green and native threads, but 1.4 only
> native. Threading is an important issue for the server side java
> applications.
>
> Green threads are very scalable ( see Volano report ),
Yes, but only on
Hi,
Blackdown JVM 1.3 support green and native threads, but 1.4 only native.
Threading is an important issue for the server side java applications.
Green threads are very scalable ( see Volano report ), while the native
threads under Linux are a limited to few , before the server crash.
IBM
i now managed to use green threads with jre1.2.2 v3 ( i didnt get it to work
with 1.3.1 FCS-02b)
but now i get this error while the program is running (which i didnt get
witht he native on the 1.3.1)
java.lang.NoSuchMethodError: java.net.Socket: method shutdownInput()V not
found
at
Waes Bruno <[EMAIL PROTECTED]> writes:
> how do i enable green threads ? and how do i check if a java app is
> running with green threads or not ?
>
>
> export PATH="$PATH:/opt/j2re1.3.1/bin"
> export JAVA_COMPILER=NONE
> export THREADS_FLAG=green
> e
fi
vmtype=`echo ${default} | cut -c 2-`
fi
if [ "${vmtype}" = "classic" ]; then
if [ "${ttype}" = "green_threads" ]; then
LD_BIND_NOW=yes
export LD_BIND_NOW
fi
_JVM_THREADS_TYPE=${ttype}
export _JVM_THREADS_TYPE
fi
> when i run the java command with option '-green' it gives this error:
>
> Green threads support not available
> Could not create the Java virtual machine.
HotSpot Server and Client VM need native threads. They cannot work
with green threads. So, you have to choose Cla
when i run the java command with option '-green' it gives this error:
Green threads support not available
Could not create the Java virtual machine.
so it seems that there is no support for green threads anymore in
'j2re-1.3.1-02b-FCS-linux-i386.bin'
although there is a /bi
well ... it is running native threads then ...
that .java_wrapper file should decide if i want native or green threads
doesnt it ?
then why doesnt it do it
bruno
-Original Message-
From: Wilhelm *Rafial* Fitzpatrick [mailto:[EMAIL PROTECTED]]
Sent: vrijdag 7 juni 2002 2:17
To: Waes
At 4:43 PM +0200 6/6/02, Waes Bruno wrote:
>how do i enable green threads ?
>and how do i check if a java app is running with green threads or not ?
>
>
>export PATH="$PATH:/opt/j2re1.3.1/bin"
>export JAVA_COMPILER=NONE
>export THREADS_FLAG=green
>export THRE
how do i enable green threads ?
and how do i check if a java app is running with green threads or not ?
export PATH="$PATH:/opt/j2re1.3.1/bin"
export JAVA_COMPILER=NONE
export THREADS_FLAG=green
export THREADS_TYPE=green_threads
is in my bashrc file
but i dont think it runs
Wilhelm,
> I'm using the 1.3.1_02 version of the blackdown JDK with mozilla RC2
> on PPC. I'm trying to work around the fact that various applets
> SIGSEGV the JVM, and I've discovered via testing in appletviewer that
> these same applets work fine when I run the J
I'm using the 1.3.1_02 version of the blackdown JDK with mozilla RC2
on PPC. I'm trying to work around the fact that various applets
SIGSEGV the JVM, and I've discovered via testing in appletviewer that
these same applets work fine when I run the JVM with green threads.
No
Hi List
I'm using the JDK 1.3.0 on a PPC machine.
I need the JRE to run Green Threads per default.
How do I change this?
Best regards,
Jacob Vennervald
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
> "Uncle" == Uncle George <[EMAIL PROTECTED]> writes:
[...]
> I think that you will notice 1000hz on a 75mhz machine. Its probably less
> noticeable on a newer 1gHZ machine. So I suppose this depends on the
> evolutionary point of processors that you want to try this on.
> Maybe Linux needs a
On Wed, Feb 20, 2002 at 02:14:37PM -0500, Uncle George wrote:
> Maybe Linux needs a scheduler module?
http://resourcemanagement.unixsolutions.hp.com/WaRM/schedpolicy.html
regards
john
--
"They eat cold meat for breakfast and make jokes about gzip."
- Rik Hemsley on KDE developers
-
scheduling services ), are now done more frequently.
> but with 1 gighz machine, 1/1000sec is ~1million instructions before an
> jiffy happens. So if your threads complete before the million, then u r
> in great shape. If they take longer, then that task may be scheduled out
&g
On Tue, Feb 19, 2002 at 01:18:17PM -0800, Veda Narayanan wrote:
> All,
> I agree with jim. We need to share information about this as this have
> direct impact on java/linux combination as a Enterprise platform. This
> should be addressed in a broad spectrum than just changing a parameter in
Hello all,
I need to build the Jdk 1.1.8 on a x86 linux box. Where can i get the diff's
?. I am looking for them at blackdown, and i am unable to locate them. Any
pointers will be appreciated.
Thanks in advance for your help.
Regards
- asit
Lets post this question to linux
mailing list.
Reg
Ved
-Original Message-From: Jim Hazen
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 19, 2002
11:49 AMTo: BlackdownSubject: Re: Why do threads take so
long to wake up underlinuxWhy not have this
discussion on this list
CPU hangry applications
like jave will see benefit of this as long computationaly intensive
threads will be more frequently interrupted by small interactive tasks.
The problem is that current linux scheduler is not optimal
(2.5.X kernels now has O(1) scheduler and some realtime patches which
should
ums are 10 times smaller thus especially CPU hangry applications
like jave will see benefit of this as long computationaly intensive
threads will be more frequently interrupted by small interactive tasks.
The problem is that current linux scheduler is not optimal
(2.5.X kernels now has O(1) sched
r
second. The overhead in processing the interrupt. ( context save,
registers saved ). The services performed at a clock ( jiffy ) tick (
timeout services, scheduling services ), are now done more frequently.
but with 1 gighz machine, 1/1000sec is ~1million instructions before an
jiffy happens. So
machine, 1/1000sec is ~1million instructions before an
jiffy happens. So if your threads complete before the million, then u r
in great shape. If they take longer, then that task may be scheduled out
to some other task that is also ready to run. I am not sure if a
Threaded task total quantum(s) are
How
does this affect the rest of the performance of the machine, are there any
downsides?
-Original Message-From: Jim Hazen
[mailto:[EMAIL PROTECTED]]Sent: February 18, 2002 8:46
PMTo: BlackdownSubject: Re: Why do threads take so long
to wake up underlinuxOk, I've re
Ok, I've rebuild the a kernel with HZ 1000 (and bumped CLOCKS_PER_SEC to 1000 too).
The output is now closer to what one would expect. Also if you always sleep for 10ms, you get a total time of 10 ms for nearly every run (some runs were 11-13ms, but most ~27 were 10).
Hope this helps. I
On Tue, Feb 12, 2002 at 10:07:59AM -0800, Fengguang Song wrote:
>
> It's interesting. Did anybody try rebuilding the kernel with HZ=1000?
> I'm also curious about it.
Well I've done this long time ago - it helps for the 'sleep' case
however linux latency might be quite huge thus it could be stu
; BTW, does the fix proposed to change the kernel with HZ=1000 worked??
>
> Reg
> Ved
>
> -Original Message-
> From: Martin, Stephen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 06, 2002 12:55 PM
> To: '[EMAIL PROTECTED]'
> Subject: Why do thre
PROTECTED]]
Sent: Wednesday, February 06, 2002 12:55 PM
To: '[EMAIL PROTECTED]'
Subject: Why do threads take so long to wake up underlinux
I've been doing some benchmarks on my machine (a dual 733 running redhat
7.2)
and there seems to be a 20 millisecond penalty for doing a sleep or a wai
On Wed, Feb 06, 2002 at 03:54:45PM -0500, Martin, Stephen wrote:
> I've been doing some benchmarks on my machine (a dual 733 running redhat
> 7.2)
> and there seems to be a 20 millisecond penalty for doing a sleep or a wait.
> Here
> This is pretty much consistent on all jvms that i've tried black
I've been doing some benchmarks on my machine (a dual 733 running redhat
7.2)
and there seems to be a 20 millisecond penalty for doing a sleep or a wait.
Here
is code that illustrates it:
try {
for (int i = 0; i < 30; i++) {
long start = System.currentTimeMillis();
Hi,
I've got the following problem starting my application in
the green threads mode:
/usr/local/jdk1.3.1/bin/i386/green_threads/java: error while loading shared
libraries: /usr/local/jdk1.3.1/jre/lib/i386/libpreemptive_close.so:
undefined symbol: pthread_kill
do you have a clue?
iginal Message-
From: Hong Zhou [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 18, 2001 2:31 AM
To: A6<10G
Subject: Re: [blackdown1.3.1] segmentation fault using green threads
To me, green thread has less problems on Linux. I
suspect that your computer does not support green
thre
It is first to post the message to this newsgroups.
I ported the blackdown jvm to my boards.
The system spec for my board is
CPU:StrongArm sa1110
Flash memory: 32 M
RAM:32M
When I use the native thread, My java application works well.
shell) java -native -jar Myjar.jar
But W
Is there some special setting
that I need on red hat linux to allow the spawning of new threads?
Thanks in advance.
CHEERS> SAM
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
d-on. Any opinions
> from those who've hit the wall when scaling up Java on Linux?
NxM is actually pretty well proven as being a better way to
scale. It's also been proven that it's fairly complex to implement
properly. In general, there are a lot of issues with having N
kernel-lev
On Wed, Oct 03, 2001 at 06:32:11PM -0700, Dan Kegel wrote:
> root wrote:
> >
> > On Wed, Oct 03, 2001 at 02:22:51PM -0700, Dan Kegel wrote:
> > > Nathan Meyers wrote:
> > > > The current Linux implementation of POSIX threads uses the clone() kernel
> >
On Wed, Oct 03, 2001 at 06:50:48AM -0700, Avi Cherry wrote:
> At 2:16 PM +0200 10/3/01, Florent Coste wrote:
> >I'm not a kernel guru too,
> >
> >but what know is that :
> >java threads are mapped to posix threads (linuxthreads in the glibc). The
> >linuxt
At 2:16 PM +0200 10/3/01, Florent Coste wrote:
>I'm not a kernel guru too,
>
>but what know is that :
>java threads are mapped to posix threads (linuxthreads in the glibc). The
>linuxthreads library uses the kernel threads, which directly map
>into a 'process
>lik
> In Linux:
> Well, I hope to hear it from you guys. ;) ... since it is not in the book
> that I have and I am not a kernel guru ... and how is it different between
> 2.2 and 2.4.
Hello all,
I'm not a kernel guru too,
but what know is that :
java threads are mapped
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Re-Reading the O'Reilly book "Java Threads 2nd Edition by Scott Oaks and
Henry Wong", in summary:
In Windows:
* Threads are timesliced
* With SMP, each CPU will select a currently running thread
( page 147 ) ( Therefore, no need to
Hi,
I'm trying to run java with native threads option with Blackdown jdk118_v2
for arm. I get the following error message and I'd like to know if anyone
has an idea of how I can solve this problem. It seems that jdk118_v2 is the
only one with native threads support for arm, correct
Hello,
I have a C routine for image segmentation and I
use it through the JNI. Each of the four threads used, reads a diffrent image,
it segments the image, extracts some features and returns them to the Java
program.But unfortunately the threads can not work together.Has anyone an idea
of
Valerio Ferrucci wrote:
> Hi,
> I'm building a mutli thread C application using JNI and Invocation API to load
> Java Virtual Machine and call Java code.
> To launch a new thread I used the call:
>
> pthread_create
>
> Now that I link JNI, whit which call have I to substitute "pthread_create"?
>
Hi,
I'm building a mutli thread C application using JNI and Invocation API to load
Java Virtual Machine and call Java code.
To launch a new thread I used the call:
pthread_create
Now that I link JNI, whit which call have I to substitute "pthread_create"?
That is, how can I launch a new thread wi
Hi!
On Son, 28 Jan 2001 V wrote:
> Hi,
>
> I installed a Blackdown Java 1.1.8 on my pc and tried to start an
> application!
>
> I got following error message:
>
> "Unable to initialize threads - cannot find class java/lang/Thread"
>
> Does anyone know
Hi,
I installed a Blackdown Java 1.1.8 on my pc and tried to start an
application!
I got following error message:
"Unable to initialize threads - cannot find class java/lang/Thread"
Does anyone know why I get this message?
IBM Java 1.1.8 does not show up that error message - so I
On Thu, 11 Jan 2001, Joseph Shraibman wrote:
> Scott Murray wrote:
> >
> > Nowadays the buffers are purely used for buffering access to the block
> > devices (e.g. disks). Pretty much everything else is now cached in the
> > page cache.
>
> That still doesn't answer my question. If everything i
Scott Murray wrote:
>
> On Wed, 10 Jan 2001, Joseph Shraibman wrote:
>
> > On a related note, what is the difference between "buffered" and
> > "cached" memory? I've noticed that with 2.4.0 there is barely any
> > buffered.
>
> Nowadays the buffers are purely used for buffering access to the b
On Wed, 10 Jan 2001, Joseph Shraibman wrote:
> On a related note, what is the difference between "buffered" and
> "cached" memory? I've noticed that with 2.4.0 there is barely any
> buffered.
Nowadays the buffers are purely used for buffering access to the block
devices (e.g. disks). Pretty mu
17:41
> To: scott murray; KIRKBRIDE Rob ([EMAIL PROTECTED])
> Cc: [EMAIL PROTECTED]
> Subject: Re: 2.4 kernel and threads
>
>
>
> On a related note, what is the difference between "buffered" and
> "cached" memory? I've noticed that with 2.4.0 there is b
On Thu, 4 Jan 2001, Joseph Shraibman wrote:
> >From README.linux to the 1.2.2 distrib:
> * If you get OutOfMemory errors when you try create more than xxx
> threads you'll have to increase the number of tasks supported by
> kernel (the default is 256 per user). Change
>From README.linux to the 1.2.2 distrib:
* If you get OutOfMemory errors when you try create more than xxx
threads you'll have to increase the number of tasks supported by
kernel (the default is 256 per user). Change NR_TASKS in
/usr/src/linux/include/linux/tasks.h and recompile th
Scott Murray wrote:
>
> On Sun, 19 Nov 2000, Volker wrote:
>
> > Hi,
> >
> > does HotSpot only support "native threads" but not "green ones"?
>
> Yes, that seems to be the case with all of the the existing HotSpot VMs.
>
Sun made a de
On Sun, 19 Nov 2000, Volker wrote:
> Hi,
>
> does HotSpot only support "native threads" but not "green ones"?
Yes, that seems to be the case with all of the the existing HotSpot VMs.
Scott
--
=
Hi,
does HotSpot only support "native threads" but not "green ones"?
Best regards
Volker
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Consider the following scenario.
Class A creates and starts a thread. This thread ( called LocalServer ), uses
ServerSocket(0) to choose a port that is available, and listens for incoming
connections on that port. The port on which the LocalServer is listening must be
passed to A, so that A can
Hello,
I have some kind of file system permissions problem.
I installed the native threads jdk-1.1.7 on my Red Hat machine
(6.0, 6.2??). When I run javac, I get a complaint about
inability to create a file in /proc. The permissions on
/proc look OK. Any help?
Bill Halchin
ng to
> "classes.zip" in that same directory to fix the error message I was getting.
> It might help you with some other, misbehaving Java program.
>
> From: Martin Gustavo Dobro <[EMAIL PROTECTED]>
> Date: Wed, 26 Jul 2000 17:00:18 -0300
> To: "'linux'
o Dobro <[EMAIL PROTECTED]>
Date: Wed, 26 Jul 2000 17:00:18 -0300
To: "'linux'" <[EMAIL PROTECTED]>
Subject: RE: Unable to initialize threads
Hello
I find a page in Oracle Technet
I've a same problem and I will probe with this.
http://www.oracle.com/s
?
> From: linux <[EMAIL PROTECTED]>
> Date: Wed, 26 Jul 2000 10:42:59 -0400
> To: <[EMAIL PROTECTED]>
> Subject: Unable to initialize threads
>
> I downloaded JDK118_v1 so that I could run the Oracle 8i installer. The JDK
> README seemed clear, so I put the JDK directory
tried
running some of the Java demos. They work just fine using either Netscape
or the appletviewer. But whenever I try to invoke jre, I get the error:
Unable to initialize threads: cannot find class java/lang/Thread
Could not create Java VM
I've tried several things that the documentation seem
> Maybe another thread with a higher priority is blocking the system. Are
i didn't hassle around with thread priority, so i think that all should have
the same
> you sure that all your threads are yield()ing sometimes? Even if you have
yep, since i have a farm-pattern approach,
Hi!
Maybe another thread with a higher priority is blocking the system. Are
you sure that all your threads are yield()ing sometimes? Even if you have
only threads with same priorities it is not guaranteed, that your
yielding threads are woken up after a time.
On Mon, 10 Jul 2000, Bruno
Bruno Boettcher <[EMAIL PROTECTED]> writes:
> computation is made by methods (which may contain yields) called through a
> select in the run-method of each thread, after computation the thread is
> blocked by a self-build semaphor. Each thread has a wake method, which sets
> the desired computat
ll
> the work, giving you the impression that the program is making
> progress, while all other threads are still blocked and not waken.
but that's not what the debugger reports when using the timer, and hitting
threads, at any time is see different threads alive, without the timer, a
ally mean it, it cannot wake up any
thread, period.
What I think really happened is that your timer thread T is doing all
the work, giving you the impression that the program is making
progress, while all other threads are still blocked and not waken.
-
hello,
i have programmed a SPICE-like simulator where each element to simulate is in a
thread. Now when running i send through the tree representing the circuit an
impulse for some sort of computation and wait for completion before launching
the next step.
I noticed that for some reason the whol
ake its own loading decisions. Given the many limited resources one
can use up - threads, CPU, real and virtual memory, file descriptors, disk
space, and so on - and the unique behaviors of every platform, it's a nasty
problem to try to solve.
Nathan
>
>
>
to heavy demand from the Java community. Even Solaris, with its
boasts of a highly tuned threading system, hasn't been such a happy place to
build highly scalable Java server products. Yes, Linux can do better, but it's
still a very long way to the "threads are free" ethos behind
situation, we have control over the Linux kernel
(it is open source, afterall) but small access to the Java
implementations. This whole thread started when I said that one of the
Sun engineers claims that Hotspot can't really work with green
threads. That means that Sun's going to rely on
On Mon, Jun 12, 2000 at 09:36:27AM -0700, Matt Welsh wrote:
>
> Juergen Kreileder <[EMAIL PROTECTED]> writes:
> > I still haven't seen one good argument for using thousands of threads
> > except for working around Java's _current_ IO limitations and doing
> &
language. Add serialization
and you get a distributed concurrent object oriented programming language.
Strange enough, most people don't see it this way and argue against
using lots of threads. However, for many cases, threading greatly simplifies
design and programming, especially for event-d
>>>>> "Matt" == Matt Welsh <[EMAIL PROTECTED]> writes:
> Michael Thome <[EMAIL PROTECTED]> writes:
>>
>> Agreed - beginners *do* tend to use too many threads,
> This has nothing to do with "beginners"!
Sorry - I didn&#x
Michael Thome <[EMAIL PROTECTED]> writes:
>
> Agreed - beginners *do* tend to use too many threads,
This has nothing to do with "beginners"!
Currently, you *cannot* write a Web server in Java without using one
thread per socket connection. You can limit the number of
Juergen Kreileder <[EMAIL PROTECTED]> writes:
> I still haven't seen one good argument for using thousands of threads
> except for working around Java's _current_ IO limitations and doing
> better on benchmarks which test work-arounds for these IO limitations.
This is
1 - 100 of 357 matches
Mail list logo
