For anyone interested: j-Interop implements DCOM wire protocol (MSRPC) to enable development of Pure Bi-Directional, Non-Native Java applications which can interoperate with any COM component.The implementation itself is purely in Java and does not use JNI to provide native access,thus being
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
Q> To: Quan, William [NGC:B866:EXCH]
WQ> Cc: '[EMAIL PROTECTED]'
WQ> Subject: Re: Linux JVM: JNI allow putmsg() syscalls in native code?
WQ> William Quan <[EMAIL PROTECTED]> writes:
>> Q1.) Why is the JVM eclipsing my getmsg() and putmsg() syscalls with
&
Title: RE: Linux JVM: JNI allow putmsg() syscalls in native code?
The LD_PRELOAD is working out after all. I set this *inside* of my '.java_wrapper'
instead of on the command line. This prevents the process from hanging like before.
LD_DEBUG=symbols,binding reveals the
William Quan <[EMAIL PROTECTED]> writes:
> However, when I attempt to do the command:
> 'LD_PRELOAD=/usr/lib/libLiS.so ... java' The process hangs(long
> pause and no sign of completion in sight)- so i kill the process.
> Q3.)Any ideas as to what might be the cause for this hangup using
> LD_PRE
Title: RE: Linux JVM: JNI allow putmsg() syscalls in native code?
Juergen,
Thanks for your help.
The LD_DEBUG shows the following:
31212: symbol=putpmsg; lookup in file=/lib/libc.so.6
31212: binding file /home/imslab/jets1000dev/dlpi/libdlpi.so to /lib/libc.so.6: symbol
l use
instead of "java") that is linked with libLiS.so.
> Q2.) Does the following restriction apply to the linux 1.3.1 (native
> threads)?
No, the restriction only applies to the green threads VM.
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://www.bla
Title: Linux JVM: JNI allow putmsg() syscalls in native code?
GIVEN:
--
I am working on a Java Network Application that can send/receive raw Ethernet packets.
I bypass the TCP/IP stack and pass them to a DLPI provider. Currently, I am attempting
to use LiS-2.12 (a.k.a LINUX STREAMS: http
tees about whether certain C++
language
features, like C++ exceptions and RTTI, are valid in the context of
native
code. These C++ language features typically require all modules in the
system to be
compiled with the features enabled, and typically require run-time
support.
In this case there is l
Hello all-
I am working on an application that uses the JNI to talk between
native code written in C++ and Java. When native code called through
the JNI throws an exception, the stack will be unwound past a valid catch
statement, resulting in a call to __default_terminate() and finally
I am working on an application that uses drag and drop and am attempting to
create my
own DragGestureRecognizer and am getting this message when I try to start a
drag operation.
If I use the default recoginzer every thing is fine. Is there something that
needs to be done in
the recognizer that wou
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
I am using Java to call some Native Code, the Native
Code basically makes a non blocking connect call and
establishes a Socket Connection. I am facing a few
problems though.
For one if 'connect' returns, errno (see man page for
errno, if you don't know what I am talking a
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
Hello,
After having many problems I could debug native methods with jdb. To be
able to set breakpoints I had to call a native method containing the
following line:
__asm__("int $0x3");
I do not like this approach because I have to modify my code and recompile
a java class if I wan
> "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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, May 29, 2000 at 12:02:11PM -0700, Todd Papaioannou wrote:
> Apart from gcj, which I am having trouble using with the jdk1.2.2 collection
> classes, does anyone know of any other methods of generating native
> instruction codes on l
Apart from gcj, which I am having trouble using with the jdk1.2.2 collection
classes, does anyone know of any other methods of generating native
instruction codes on linux from java class or source files?
thanks
Todd
---
Todd
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'm
trying to use two java threads t1 and t2, and each one uses exec() to start the
same C native application. It seems JVM (BlackDown 1.1.8 v1) never
switches from t1 to t2. The output looks like:
In
thread t1: i = 0
In
thread t1: i = 1
In
thread t1: i = 2
...
of
> -->them being excessive numbers of repaints... especially when you drag
>
> OK, so the next Q. Where do the problems come from?
JDK1.2, in its new Graphics2D implementation, takes over a lot of
rendering functionality from the native windowing system. Many
operations that JDK1.1
On Fri, 21 Jan 2000, Nathan Meyers wrote:
-->> By 'background' I meant a Java Frame (Window). So, eg. I have the main
-->> frame of my aplication an a dialog box. Moving dialog makes the main
-->> frame repaint itself. This takes particularly much time. Generally, the
-->> same Java application (
Marek Gmyrek wrote:
>
> On Fri, 21 Jan 2000, Chris Kakris wrote:
>
> -->> Processor utilization is not so bad, until I move a window and a window
> -->> in background has to repaint itself. Repainting takes a time of ca. a few
> -->> seconds. During that time the processor is busy almost to 100%
On Fri, 21 Jan 2000, Chris Kakris wrote:
-->> Processor utilization is not so bad, until I move a window and a window
-->> in background has to repaint itself. Repainting takes a time of ca. a few
-->> seconds. During that time the processor is busy almost to 100%.
-->
-->Are you by any chance us
Marek Gmyrek wrote:
>
> I use the same system (RH6.1) with Blackdown JDK1.2 RC3 and have the same
> observations. Both native and green versions are very slowly, especially
> with GUI stuff, when compared to jdk1.1.8 (v1).
>
> Processor utilization is not so bad, until I m
On Thu, 20 Jan 2000, Marek Gmyrek wrote:
> observations. Both native and green versions are very slowly, especially
> with GUI stuff, when compared to jdk1.1.8 (v1).
>
> Processor utilization is not so bad, until I move a window and a window
> in background has to repaint its
Hi,
-->Here is what I see with Linux. I am running on a freshly installed RedHat
-->6.1 machine. With either JDK, running in native threads is absolutely
-->crippling. There seems to be a serparate JDK process ID for each running
-->thread, or otherwise something is casuing it to f
Daniel Stux wrote:
>
> Hi folks,
>
> I've just installed two versions of the JDK1.2.2 for linux: Sun's RC2, and
> Blackdown's RC3. I am experiencing the wierdest behavior I have ever seen
> for a JDK.
>
I didn't see someone else mentioning this: did you try IBM's JDK?
/Oliver
--
or a JDK.
>
> Here is what I am *used* to seeing. We run Java all day long on Solaris
> Sparc and x86 and Windows NT. With green threads, things are slow as hell,
> and the processors are kept very busy, even when the program is idle. With
> native threads, everything zips along nicely
Hi Jonathan,
You mentioned 2.4 kernel. Do you know when it is going to
come out?
Jacob Nikom
Jonathan Doughty wrote:
>
> Daniel Stux wrote:
>
> > Here is what I see with Linux. I am running on a freshly installed
> > RedHat 6.1 machine. With either JDK, running
On Wed, Jan 19, 2000 at 02:36:30PM -0500, Daniel Stux wrote:
> Here is what I see with Linux. I am running on a freshly installed RedHat
> 6.1 machine. With either JDK, running in native threads is absolutely
> crippling. There seems to be a serparate JDK process ID for each running
>
On Wed, Jan 19, 2000 at 02:36:30PM -0500, Daniel Stux wrote:
> Here is what I see with Linux. I am running on a freshly installed RedHat
> 6.1 machine. With either JDK, running in native threads is absolutely
> crippling. There seems to be a serparate JDK process ID for each running
>
Daniel Stux wrote:
> Here is what I see with Linux. I am running on a freshly installed
> RedHat 6.1 machine. With either JDK, running in native threads is
> absolutely crippling. There seems to be a serparate JDK process ID
> for each running thread, or otherwise something is c
h green threads, things are slow as hell,
and the processors are kept very busy, even when the program is idle. With
native threads, everything zips along nicely.
Here is what I see with Linux. I am running on a freshly installed RedHat
6.1 machine. With either JDK, running in native threads is absol
I've not seen a way to call say.. libc printf from
java. printf is usually wrapped in a native function
that matches java's calling method. More recently
this is done through the java native interface.
You have probably seen the 'trail' for calling native
functions from
Hi,
How can I get a reference to a native class in a shared library and use the functions
? An example would be very welcome !!
Thanks ...
E-Mail : [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
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
We don't have to argue about native vs. green threads since the
Blackdown JDK 1.2.2 release does both.
I understand why people need native threads, but I need green threads on
Linux for handling a large number of dedicated connections to a pure
Java server (see
http://developer.java.su
Though, by its nature, green thread does not support SMP. Any comment /
Steve
- Original Message -
From: "Weiqi Gao" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 08, 1999 9:26 AM
Subject: Re: Native vs. green threads
> Scott Murray wro
On Tue, 7 Dec 1999, Weiqi Gao wrote:
> Scott Murray wrote:
> >
> > On Tue, 7 Dec 1999, Matt Welsh wrote:
> > >
> > > [EMAIL PROTECTED] (Nelson Minar) writes:
> > > >
> > > > However, I disagree that native threads are required for seri
Scott Murray wrote:
>
> On Tue, 7 Dec 1999, Matt Welsh wrote:
> >
> > [EMAIL PROTECTED] (Nelson Minar) writes:
> > >
> > > However, I disagree that native threads are required for serious
> > > applications. Green threads work surprisingly well fo
On Tue, 7 Dec 1999, Matt Welsh wrote:
>
> [EMAIL PROTECTED] (Nelson Minar) writes:
> >
> > However, I disagree that native threads are required for serious
> > applications. Green threads work surprisingly well for many
> > applications. In some, they work bet
[EMAIL PROTECTED] (Nelson Minar) writes:
>
> However, I disagree that native threads are required for serious
> applications. Green threads work surprisingly well for many
> applications. In some, they work better. I recently wrote a spider
> program that was invoking anoth
If you cannot changed the name of your function in the library,
you have to create JNI wrapper for this function. You call this
wrapper from Java using JNI and make your function call from this
wrapper. You also have to link your shared C++ library.
Jacob Nikom
[EMAIL PROTECTED] wrote:
>
> Hi
Hi,
Is it possible to use functions from an existing shared library (written in C++) in
Java ???
I read that I have to use the JNI. Can anyone tell me exactly how this works
Thanks ...
E-Mail : [EMAIL PROTECTED]
--
To UNS
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
On Mon, Nov 29, 1999 at 05:30:17PM -0500, Jacob Nikom wrote:
> Was HotSpot ported to Linux?
>
If it has been, it shouldn't manifest itself until JDK1.3.
BAPper
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Was HotSpot ported to Linux?
Jacob Nikom
Andy Choi wrote:
>
> Hi all,
>
> I have got a problem using native thread and hotspot with rc2. When i
> try to run java, it would gives me the following messages.
>
> /usr/local/jdk1.2.2/bin/i386/native_threads/java: erro
Hi all,
I have got a problem using native thread and hotspot with rc2. When i
try to run java, it would gives me the following messages.
/usr/local/jdk1.2.2/bin/i386/native_threads/java: error in loading
shared libraries:
/usr/local/jdk1.2.2/jre/lib/i386/native_threads/libhpi.so: symbol
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
>>>>> Aaron Mulder writes:
Aaron> Is there any workaround? I installed Oracle for Linux, and
Aaron> all it's tools run via java -native, and there are *ever so
Aaron> many* scripts to edit to change that! ;)
You can modify jdk117_v3/bin/.jav
Is there any workaround? I installed Oracle for Linux, and all
it's tools run via java -native, and there are *ever so many* scripts to
edit to change that! ;)
Thanks,
Aaron
P.S. to Nathan: I have a /proc filesystem and the kernel is compiled from
the Red Hat 2.2.12 s
>>>>> 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
=>From: "Ted Neward" <[EMAIL PROTECTED]>
=>...
=>Does "had good luck" mean without having to modify LD_LIBRARY_PATH? Or
=>/etc/ld.so.conf?
Yes. If you run the java script with "sh -x" (you have to give it the
full path to the script, too, IIRC) you'll see that it calculates a
CLASSPATH and a
From: dave madden <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, September 30, 1999 3:04 PM
Subject: Re: "proper" place for the .so native libraries
> =>From: Brett Smith <[EMAIL
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
=>From: Brett Smith <[EMAIL PROTECTED]>
=>...
=>Where is the "proper" location for the *.so native library files?
I've had good luck putting them under:
.../jdk-1.2/jre/lib/i386/
appropriate platform here!
=>On
Where is the "proper" location for the *.so native library files?
One JNI tutorial said the following:
LD_LIBRARY_PATH='pwd'
export LD_LIBRARY_PATH
When I tried this, it caused a "full thread dump" upon calling the
native method.
Any ideas why?
Also, do
if I'm wrong.
I very much suspect so...
At 08:30 9/14/99 +0200, Pierre Legay wrote:
>Hello,
>when I execute a very simple program ( jre Hello.class) with the
I'll assume that you meant:
jre Hello
>THREADS_FLAG=native
>I have the message:
>SIGSEGV11* segmentat
jre Hello.class) with the
> THREADS_FLAG=native
> I have the message:
> SIGSEGV11* segmentation violation
> full thread dump:
> Monitor Cache Dump:
> registered monitor dump:
>
> What is the solution ?
>
> --
Hello,
when I execute a very simple program ( jre Hello.class) with the
THREADS_FLAG=native
I have the message:
SIGSEGV11* segmentation violation
full thread dump:
Monitor Cache Dump:
registered monitor dump:
What is the solution
Java Plug-in is not available for Linux.
Nathan
> Hello,
>
> running a specific applet on Linux gives the following error
> in the Netscape Java Console:
>
> warning: running 1.2 version of SwingUtilities
> # Applet exception: error: java.lang.Unsatisfie
Hello,
running a specific applet on Linux gives the following error
in the Netscape Java Console:
warning: running 1.2 version of SwingUtilities
# Applet exception: error: java.lang.UnsatisfiedLinkError: native method
java/security/AccessController.doPrivileged not found:
/usr/lib/netscape
-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
This is to announce, for the benefit of those using my "Profiler" native
profiler for JDK1.2, that an update has been posted - please grab the
latest version. Description at:
http://www.teleport.com/~nmeyers/FreeWare/#Profiler
New bits at:
http://www.teleport.com/~nmeyer
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
Hi guys...
Playing with native methods, I have created a very basic program that
creates a TCP/IP socket from Java by using the corresponding C call (i.e.,
socket()).
My code (excluding error handling parts) is something like:
// File NativeSocketApplication.java
public class
ANNOUNCEMENT
This is to announce the availability of Profiler, a JDK1.2 profiler that
reports how much time is being spent in native code.
Under the covers, Java is always running native code: the JVM, native
libraries, JIT-compiled code. Profiler allows you to see where the time
is really
Dimitris Terzis wrote:
>
> Hi guys...
>
> Playing with native methods, I have created a very basic program that
> creates a TCP/IP socket from Java by using the corresponding C call (i.e.,
> socket()).
You are sending your output through two different mechanisms. The
System.o
Hi guys...
Playing with native methods, I have created a very basic program that
creates a TCP/IP socket from Java by using the corresponding C call (i.e.,
socket()).
My code (excluding error handling parts) is something like:
// File NativeSocketApplication.java
public class
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
-
From: Dimitris Terzis <[EMAIL PROTECTED]>
To: 'Java-Linux mailing list' <[EMAIL PROTECTED]>
Sent: Tuesday, August 31, 1999 4:42 PM
Subject: Native library problem
> Hi guys...
>
> Someone give a hint please, because I 'm next to madness and I don't want
.
More specifically, I have a simple program, test.c, which implements a very
basic "Hello World"-type native method. I compile the program using
gcc -I $JDK12_HOME/include -I $JDK12_HOME/include/linux -fpic test.c
/object1.o /object2.o -o test
and it produces the necessary executable
-
From: Dimitris Terzis <[EMAIL PROTECTED]>
To: 'Java-Linux mailing list' <[EMAIL PROTECTED]>
Sent: Tuesday, August 31, 1999 4:42 PM
Subject: Native library problem
> Hi guys...
>
> Someone give a hint please, because I 'm next to madness and I don't want
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
Dimitris Terzis wrote:
>
> Hi guys...
>
> Someone give a hint please, because I 'm next to madness and I don't want to
> break my machine... I have a very-very simple native library, say test_lib,
> which I try to load with System.loadLibrary("test_lib"). T
Hi guys...
Someone give a hint please, because I 'm next to madness and I don't want to
break my machine... I have a very-very simple native library, say test_lib,
which I try to load with System.loadLibrary("test_lib"). The £$^£@& compiler
insists that it's not in
"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&#
1 - 100 of 296 matches
Mail list logo
