scheduling, communication,
etc. There have been many other similar threads packages written over
the years, used by apps that need multi-threading but need to run on
operating systems that either don't support threads, or do it
inadequately for the application. Native threads is just that,
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,
Henrique
--
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 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
> "Urban" == Urban Widmark <[EMAIL PROTECTED]> writes:
Urban> On Wed, 7 Jun 2000, Andrew Majercik wrote:
>> And there-in lies the rub, because I am trying to find a viable
>> JRE for shipping a product. :)
Urban> Sorry, I need to read $subject more carefully.
>> Does any
On Wed, 7 Jun 2000, Andrew Majercik wrote:
> And there-in lies the rub, because I am trying to find a viable JRE for
> shipping a product. :)
Sorry, I need to read $subject more carefully.
> Does anyone know who to contact?
The blackdown people are on this list, they probably already know.
Ahhh!
And there-in lies the rub, because I am trying to find a viable JRE for
shipping a product. :)
Does anyone know who to contact?
Thanks,
Andrew
>From: Oscar Carrillo <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: JRE 1.1.8 Native Threads support mi
hten us?
> > I posted an inquiry before but got no reply.
> >
> > I had to eventually use the IBM JRE 1.1.8, which only supports native threads.
> > I would probably make an RPM of the balckdown 1.1.8 if I could figure out the
> > native threads support.
>
> The na
On Wed, 7 Jun 100, Oscar Carrillo wrote:
> I couldn't figure this out either. Can someone please enlighten us?
> I posted an inquiry before but got no reply.
>
> I had to eventually use the IBM JRE 1.1.8, which only supports native threads.
> I would probably make an RPM of
I couldn't figure this out either. Can someone please enlighten us?
I posted an inquiry before but got no reply.
I had to eventually use the IBM JRE 1.1.8, which only supports native threads.
I would probably make an RPM of the balckdown 1.1.8 if I could figure out the
native threads su
Hi,
I've been reading the FAQ and the Blackdown site about Native threads, and
I'm having trouble getting the Native threads package for jre 1.1.8 under
Intel linux. The web page claims 1.1.8 to have the native threads support
built in on one section of the web p
Hi,
I've compiled a server application under blackdown's JDK 1.1.8
with native threads. But I can't see any libraries for native
threads to be run under the JRE.
It seems every other version has them for the JRE. What is
different about 1.1.8?
I don't have the option to mo
On Sat, Jun 07, 2036 at 07:48:37PM -0700, Joseph Shraibman wrote:
> Run the following with green threads and you get only H's. Run it with native
> threads and you get H's mixed with L's
The native threading mechanism on Linux doesn't offer many thread
I think you could rephrase that as "In Java, Thread priorities don't
work". :-) The language guarantees about thread priorities are probably
weaker than you expect. Quoth the language spec:
"Every thread has a priority. When there is competition for processing
resources, threads with higher prior
Juergen Kreileder <[EMAIL PROTECTED]> wrote:
Jurergen> Don't use thread priorities for synchronization!
I'm not. I have an rmi server that needs to do a lot of work. I want to spin
off some time insensitve tasks into their own low priority thread so that rmi
calls that need fast responses won'
een threads and you get only H's.
Joseph> Run it with native threads and you get H's mixed with L's
Don't use thread priorities for synchronization! They are completely
different concepts. Even with thread priorities implemented your test
would fail badly on multi process
Thread priorities don't work in any JVM I've used. Java's rules are
fairly senseless, too.
I'm not sure your case qualifies as a bug, though:
> public void run(){
> //Thread.yield();
> while(true){
> System.out.print(name);
> System.out.flush
Run the following with green threads and you get only H's. Run it with native
threads and you get H's mixed with L's
/**
* threadtest.java
*
*
* Created: Mon May 1 15:35:45 2000
*
* @author Joseph Shraibman
* @version 1.0
*/
public class threadtest {
pu
threads and no JIT seems to work alright, though I
haven't tested it thoroughly.
Running with native threads (and no JIT) results in the following:
$ java -native -version
SIGSEGV 11* segmentation violation
si_signo [0]: no signal
si_errno [0]: Success
si_code [0]: SI_USER [
Hi !
I am
using jdk117_v3 on RH6.1 and RH6.0
.
Here jdb hangs if I set
the THREADS_FLAG to native , but it works properly if it equals to
green.
Any info on this?
Please let me know whether java native threads works properly on RH6.1 and
RH6.0.
Thanks in
Hi All,
When running simple JNI program under Linux "Segmentation fault" error
occured.
I've known I can avoid it using native threads.
But when setting THREADS_FLAG to "native" javac and java either hangs or
says that can't read /proc/00116 directory.
Also chan
own a problem I
was having to the native threads issue documented in the Blackdown JDK
readme file (and probably other places :-). The odd thing is, I'm using
the IBM 1.1.8 JDK. It made me wonder what the correlation between the
two JDKs was. Was IBM's JDK for linux written entirely from scr
memory size tweaks for Oracle.
I don't remember when this bug showed up first, maybe it was with
glibc-2.1.2.
Aaron> On 17 Oct 1999, Juergen Kreileder wrote:
>> >>>>> Aaron Mulder writes:
>>
Aaron> I just installed the native threads add
ource with some of the shared memory size tweaks for
Oracle.
On 17 Oct 1999, Juergen Kreileder wrote:
> >>>>> Aaron Mulder writes:
>
> Aaron> I just installed the native threads add-on to the 1.1.7 JRE
> Aaron> and whenever I try to use it (jre -native test) I
>>>>> Aaron Mulder writes:
Aaron> I just installed the native threads add-on to the 1.1.7 JRE
Aaron> and whenever I try to use it (jre -native test) I get the
Aaron> following result:
Aaron> Cannot open /proc/02891 for GCCould not create Java VM
A
Aaron Mulder wrote:
>
> I just installed the native threads add-on to the 1.1.7 JRE and
> whenever I try to use it (jre -native test) I get the following result:
>
> Cannot open /proc/02891 for GCCould not create Java VM
>
> Where the proc number chang
I just installed the native threads add-on to the 1.1.7 JRE and
whenever I try to use it (jre -native test) I get the following result:
Cannot open /proc/02891 for GCCould not create Java VM
Where the proc number changes every time... I'm using Red Hat
6.1 on a 2-proc
Hi there,
Is the jdk117_v1a (glibc version) supposed to work
on redhat 6.0 (glibc2.1, kernel 2.2.5-15) or are there glibc2.0/glibc2.1
incompatibilities at work here ?
I'm using native threads with this jdk on redhat6.0 for
a multithreaded server that used JNI. If I use a single
c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>>>>> "Juergen" == Juergen Kreileder <[EMAIL PROTECTED]> writes:
>>>>> Gene McCulley writes:
Gene> Under glibc 2.0 and SMP, the native threads version of
Gene> jdk117_v3 is unreliable.
>>>>> Gene McCulley writes:
Gene> Under glibc 2.0 and SMP, the native threads version of
Gene> jdk117_v3 is unreliable.
We are working on it.
Gene> Another problem with the Invocation API is embedding Java
Gene> GUI apps in applications that u
seems a legitimate thing
to do to me, but apparently the native threads implementation does not
expect that the main thread will be a Java native thread also. It
seems that the main thread is the one that sends SIGSTOP to all of the
threads that are Java native threads. In my case, that meant that
I had quite a few problems using native threads with JDK 1.1.7v3.
These were never resolved but the Blackdown folks said that the
forthcoming 1.1.8 release might fix some of the problems.
You should be able to use gdb to find out what's going on; you can tell
gdb to report the various si
jdk117_v3 on a glibc 2.1.2 system under a 2.2.9
single processor kernel. I am using native threads and the Invocation
API embedded in a large application. My problem is that everytime the
garbage collector runs, most of the threads seem to get SIGSTOP but
never get started again. The program even
Bart Locanthi <[EMAIL PROTECTED]> writes:
> i've been periodically trying out native threads, hoping to get full
> usage from an SMP sytem. so far, no luck. finally abstracted the problem
> into a simple, repeatable form.
>
> the following program creates M threads th
i've been periodically trying out native threads, hoping to get full
usage from an SMP sytem. so far, no luck. finally abstracted the problem
into a simple, repeatable form.
the following program creates M threads that each make and quit from N
Sockets to an SMTP_HOST.
java NT SMTP
"James H. Cloos Jr." <[EMAIL PROTECTED]> writes:
>
> But 1.1.7_v3 w/ native threads failt to output *anything*.
This is exactly the behavior we're seeing - looks like native threads
in 1.1.7_v3 are simply broken. Juergen says that he doesn't have this
prob
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I just tested it on my mostly RH60 box.
In IBM's 1.1.6, the threads alternate their output. The same occurs
in BD's 1.2 w/ native threads and in 1.1.7_v1a w/ native threads.
Both 1.2 and 1.1.7_v3 w/ green threads starve thread 2. 1.1.7
I have a very simple program which spawns two threads. Running this using
native threads on JDK 1.1.7_v3 (Red Hat 6.0 w/glibc 2.1) on a 2-way
SMP machine only allows one of the threads to run; the other doesn't
even appear to start!
Using green threads, one thread always runs while the
Does anyone know if jdk 1.1.7_v3 works with native threads under
Redhat 6.0? My big hairy lots-of-threads program is choking entirely,
deadlocking fairly early on. It works fine in Redhat 5.1. I know my
own code has concurrency bugs, but maybe part of it is the JDK's fault
as well? I can&#
Hello,
I have a couple of questions concerning the JDK ports from Blackdown and
IBM:
1- Is the Blackdown port Native threads? If so, how do I invoke them?
2- Where can I download the RPM for the Blackdown JDK that actually
*works* right after installing on RH 6.0?
3- Is the IBM JDK good at
> Hi :
>Am trying to run "jre -native -cp myClasses.zip myMainClass" and am
> getting
> a core dump when the VM comes up.. ... (GREEN Threads work fine !)
> Was running the glibc 1.1.7 v3 of blackdown jvm for x86.
>
> My machine info is :
> Red Hat Linux release 6.0 (Hedwig)
> Kernel 2.2.5-15
the behaviours might mean.
On the glibc 2.0 machine, green threads work great with both 1.1.7-v3
and 1.2-pre2. Native threads work ok, but performance is actually worse
than with green threads, although, in either case I'm finding that
1.2-pre2 is appx 5x faster than 1.1.7-v3. (Also, I followe
> So what can you do? Either of the following should work:
>
> * Run `configure' with the same prefix argument you've used for glibc 2.0.x
> so that the same paths are used.
> * Replace /lib/ld-linux.so.2 with a link to the dynamic linker from glibc
> 2.1.
>
> You can even call the dynamic
Hi,
I am using the JNI invocation API in a C (not C++) application. Calling java methods
works. But when the program calls exit() it hangs in __syscall_sigsuspend(). All
threads (native ones, creates by the JVM after JNI_CreateJavaVM()) remain in the
process list. This is the stack of the main
Jim Hazen writes:
> Same there. Blackdown is doing a great job with 1.2 considering all the
> bazillion new features it adds over 1.1. The latest rounds of Native
> threads for 117v3 work great
'cept for AWT in dlopen() loaded JNI apps. Still waiting for
the new release wit
Same there. Blackdown is doing a great job with 1.2 considering all the
bazillion new features it adds over 1.1. The latest rounds of Native
threads for 117v3 work great, but there still seem to be numerous Native
threading issues in 1.2. I'd really like to see this problem resolved
so t
Hi all-
I should start by saying "Thanks!" for all the great work that's
being done by the Blackdown folks.
Also, I'm wondering how long it might be until a native-threads
version of the JDK (either 1.1.x or 1.2) is working with glibc 2.1.
Is the problem in linuxthreads, or t
> Elena Vorisi & Edoardo Comar writes:
Elena> Hi.
Elena> excuse me, it surely is a newbie question ...
Elena> assuming my system is using glibc2.1, which resides in /lib
Elena> why can't I install a glibc2.0 in a /glibc2.0 directory under my home dir
Elena> and have only selected apps (as f
glibc21 is released, but I would have liked to be able
to overcome similar issues with other sw ...
bye,
Edo.
- Original Message -
> It is not really a "limitation", it's an incompatibility. RH6 is based
> on glibc2.1, while JDK1.2 with native threads currently only works wit
"Andy Levine" <[EMAIL PROTECTED]> writes:
>
> > How involved is it to fix the problems caused by the glibc 2.1
> > changes? Where
> > can I read more about the evolution of Linux threads from the 1.x
> > kernel on? It
> > seems almost all the sticky Java problems on Linux relate to the
> > thr
soon. Don't want
to invest too much in stuff that is not likely to be around next year.
Yet I want it to work as well on green threads as native threads. So,
how does the AWT do it?
--
Tony Dean
Linux: The choice of a GNU Generation!
-
Is this a no-no in terms of JVM running with native threads support under
glibc 2.1.1-6 on a Dual PII with 512MB RAM system running RedHat Linux 6.0
(as specified in your Bug Report)?
(I can run simple stand-alone programs, but not the Apache-JServ Servlet
engine)
OR
There exists a patch or a
Terry Sikes wrote:
>
> Nathan Meyers wrote:
>
> > There was an interesting comment in a column in the current Linux
> > Journal: evidently glibc 2.0 was an "experimental" release. Problem
> > is... it was a widely adopted experimental release. The JDK is in good
> > company: many applications we
Nathan Meyers wrote:
> There was an interesting comment in a column in the current Linux
> Journal: evidently glibc 2.0 was an "experimental" release. Problem
> is... it was a widely adopted experimental release. The JDK is in good
> company: many applications were broken by the move to 2.1, whic
Stefan Proels wrote:
> It is not really a "limitation", it's an incompatibility. RH6 is based
> on glibc2.1, while JDK1.2 with native threads currently only works with
> glibc2.0. Both have pthread support, but some details are different.
> The people porting the JDK ha
> It seems the consensus "solution" for running the 1.2 JDK under RH6 is to be
> SURE you are running green threads (in addition to disabling the JIT). All
> the associated comments seem to echo "RH6 doesn't support native threads".
> What does this REALLY me
It seems the consensus "solution" for running the 1.2 JDK under RH6 is to be
SURE you are running green threads (in addition to disabling the JIT). All
the associated comments seem to echo "RH6 doesn't support native threads".
What does this REALLY mean ?
Does this mea
Yes. I have a rather large Swing app that runs fine with 1.1.7v3
green threads, but with native threads it comes up but doesn't
paint correctly (the main window remains blank, although I can
tell from trace output that the paint code is being called and
seems to complete without error), and
FWIW, I am also seeing painting problems with 1.1.7v3, using native threads. This
manifests mainly in the menus, but occassionally the entire app comes up as a big
gray box. App came up fine in previous JDK's, and works fine on other platforms.
My system is a RedHat 6.0 on i586.
-Armen
On Thu, 13 May 1999 10:42:54 +0200, Gerald de Jong wrote:
>
>i downloaded the v3 JDK, and also the native threads stuff.
>
>i would like to RTFM about how to make use of the native threads stuff, but i
>don't know where the M is. can somebody point a finger?
The M should be
i downloaded the v3 JDK, and also the native threads stuff.
i would like to RTFM about how to make use of the native threads stuff, but i
don't know where the M is. can somebody point a finger?
--
Gerald de Jong, Beautiful Code B.V.
Rotterdam, The Netherlands, Tel. +31655893940
For me( CAldera OpenLinux 2.2) v2 native thread
also
does not work in awt/swing especially in swing application.
>
>JDK 1.1.7v2 works fine!
>
>Also volanomark won't run with v3/native.
>
--
To UNSUBSCRIBE, email to [EMAIL PROT
I'm having lots of problems with native threads in v3 - some AWT/Swing
apps don't start correctly, others work unreliably (menus that sometimes
dont respond to clicks, windows that come up blank, etc). This is
happening on both a KDE and a WindowMaker system so it doesn't appear
I'm sorry if this question has been addressed before.
I searched the mailing-list archive by the same subject but apparently
different problem that I have.
My problem is :
localhost$ java -native
results in seg faults on my system.
Here is a ldconfig -D output
-ldconfig -D
Yes, native threads are working in the 1.2 prerelease.
Green threads, this time, is a problem when used with
the JIT, but you can disable it, of course.
Russ
[EMAIL PROTECTED] on 03/23/99 11:25:09 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:(bcc: Russell Pridemore
Pardon me if this has been asked and I either didn't understand the
response, or I missed it, but...
I recall a while back that the porting team had some difficultly getting
native threads to pass the JCK in JDK 1.2. I was wondering if those issues
were ever resolved, and if the curren
> I was having this problem but one of the nice folks from the blackdown
> porting team told me how to fix it. The fix was to add the libjava.so
> file to the process space with this command.
>
> setenv LD_PRELOAD libjava.so
Thanks for the hint. I read something similar in the FAQ but it was
me
multimedia group
On Mon, 1 Mar 1999, Markus Enzenberger wrote:
>
> Hi,
>
> I have a similar problem here. I use the Invocation API with native
> threads, definitely call JNI_CreateJavaVM with a correct classpath, but
> JNI_CreateJavaVM hangs for about 30 sec, before it stops with:
>>>>> Markus Enzenberger writes:
Markus> Hi,
Markus> I have a similar problem here. I use the Invocation API
Markus> with native threads, definitely call JNI_CreateJavaVM with
Markus> a correct classpath, but JNI_CreateJavaVM hangs for about
Mark
Hi,
I have a similar problem here. I use the Invocation API with native
threads, definitely call JNI_CreateJavaVM with a correct classpath, but
JNI_CreateJavaVM hangs for about 30 sec, before it stops with:
Can't find class java.lang.System
Difficult to say more, it happens only wi
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
p until the high priority thread finishes?
Since we use LinuxThreads and SCHED_OTHER, 1.2 native threads ignores
Java thread priorities (that is valid with respect to the JLS).
1.1.7 used a trick to allow reducing a thread's priority.
Juergen
--
Juergen Kreileder, Universitaet Dor
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 a Java process using native threads
>is limited to 256 threads in the default kernel. It's possible that
>boosting NR_TASKS up and recompiling the kernel will Just Work, but I
>don't know. I also don't know the implications on kernel memory used
>or scheduler performan
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 threa
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
initely
preempt like or lower priority threads). I haven't looked at the native
thread Java scheduler, but I presume that like priority, runnable Java
threads would be mapped to like priority, runnable pthreads. In which
case, the green threads and native threads will differ wildly in their
sche
the fact that context switches in the Linux kernel are
pretty efficient.
In contrast to the Linux JDK, the Solaris JDK doesn't use pthreads for
the native threads vm. (The solaris threads library has some additional
functions: suspend, resume, ...)). Also Solaris uses the
"many-to-many"
were rather
heavyweight, since there were comments about having to ensure you have
enough process descriptors and such... It would be nice to get
clarifcation, since I've not attempted native threads because they seemed
like they'd be too heavy.
So, I have assumed (incorrectly, most like
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 Linu
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 gr
>On the other side creating native threads is an expensive operation.
>Especially on Linux, where threads are heavy-weight system processes.
Can anyone tell me whether the Linux port of native threads uses some
sort of thread reuse mechanism to cut down on the OS overhead? Ie: if
I fire up
Hi!
Nathan Meyers <[EMAIL PROTECTED]> writes:
> Did native threads ever achieve production quality in Linux JDK 1.1?
> I never had much luck with them on Linux 2.0... tended to dump core
> on me.
In kernels 2.2.0pre <= 7 I had no problems: I had run jpython (like a
shell) + t
After upgrading my Linux kernel from 2.2.0pre7 to 2.2.0pre9 (aka
2.2.0-final), native threads are broken. All complex multithreaded
applications (AWT & Swing apps especially) crash within a few seconds of
start up. Green threads are not effected. Reverting to 2.2.0pre7 removes
the problem.
Did native threads ever achieve production quality in Linux JDK 1.1? I never had
much luck with them on Linux 2.0... tended to dump core on me.
> Argh!!
>
> with java -native ANYCLASSFILE, I had:
>
> **
>
> SIGSEGV 11* segmentation violation
>
Argh!!
with java -native ANYCLASSFILE, I had:
**
SIGSEGV 11* segmentation violation
stackbase=BF9FFE70, stackpointer=BF9FF9E0
Full thread dump:
"TimerQueue" (TID:0x406788d8, sys_thread_t:0x846d858, state:CW, thread_t: t@7175,
sp:0x2f4f4f threadID:0x1947, stack_base:
I heard of the problems with native threads and servlets.
When can one anticipate a more stable version of native threads and will
this be in the 1.1.7 engine or starting with the 1.2 versions ?
Thanks, Christian
--
To
Hi all.
Under blackdown's JDK1.1.7 v1a for linux an echo program
will not work if it is run from a shell script. The same
code will work perfectly if run without the -native
argument or directly from the command line. The problem
seems to be that a call to System.in.read() will block
and never re
Interesting post. I've not read much about SIGSTOP/SIGCONT. Should native
libraries be catching SIGSTOP to yield to the garbage truck then? How are
you handling this inside the black box?
Trent Jarvi
[EMAIL PROTECTED]
rxtx maintainer
http://jarvi.ezlink.com/rxtx/
Hi,
I am not sure if this is the cuase of your problem, but the natiuve_threads
jdk uses the signals to communicate between threads including SIGUSR1,
SIGUSR2 (used by linuxthreads), SIGSTOP, SIGCONT (used to stop threads to
allow garbage collection thread to run, and SIGUNUSED which is used by
t
s are intermittent, but frequently occur when I
press a button that invokes some RMI code. Am I doing something wrong? Has
anyone else experienced this? Any clues?
-Wendy
> Moses DeJong wrote:
>
> > I have not seen much about the native threads port for 1.1.7 in the
> > mailing list ar
1 - 100 of 136 matches
Mail list logo
