Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Jul 2001 16:10:30 -0700
From:      Bill Huey <>
To:        Nate Williams <>
Cc:        Greg Lewis <>,, Ian Jenkinson <>, freebsd-java@FreeBSD.ORG, Bill Huey <>
Subject:   Re: Threads in Java on a variety of platforms
Message-ID:  <20010710161030.A2843@gnuppy>
In-Reply-To: <>
References:  <000201c1086c$433a29e0$0a64a8c0@buxtongw> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Tue, Jul 10, 2001 at 01:10:55PM -0600, Nate Williams wrote:
> > Actually, in 1.3.1 the operating system specific part of native threads
> > is restricted to essentially two or three files, so its not too difficult
> > to introduce a new threading system.
> Wow, that's great.  And, FWIW, JDK 1.4 has no green threads support at
> all, so we're going to have to use something else (which I believe you
> 1.3 port is doing), so things will change in the future.
> Nate

Yeah, the changes needed to be made are pretty minimal which is why I suggested that
doing a native threads port would easier to maintain the green threads system. The
changes are pretty much localized into one major file that contains three threading
model with #ifdef-s (solaris, pthread Linux Threads), one pthreads support file for
dealing with stuff outside of the normal Posix spec (suspension of a whole bunch of
threads outside of the currently executing one) and stuff that's randomly spread
across the entire hpi/ directory dealing with locking/condition variables, etc...

In my port, I pretty much black box as much as I can and rely solely on the
correctness of our pthreads system so that any possible blow ups would be mostly
contained within the OS specific pthreads implementation.

[BSD/OS Port Update]

BTW, I'm finally got around some of the issues that's been hampering me since
April. I got all the AWT/Motif stuff dynamically loading correctly now (after severe mangling), but it hangs when trying to open a X connection for some reason.

Ok, the symbol _dl_debug_addr is an entry point for the gdb system to break at when
loading a shared object. For some reason the function pointer call crashes gdb itself,
so I can't just run the process under gdb, hit control-C and break at the point
where it's is sleeping (from information from 'top') and find what the hell is going
on. Apparenly this is a signal delivery problem with in gdb itself and it's looking
like I'm going to be distracted dealing with rather screwy gdb code to fix this. :-\

The good thing about this is that it actually attempts to open and X connection for
the first time which means that I'm making progress again and that I'm possibly
pretty close to a pre-alpha release. ;-)


To Unsubscribe: send mail to
with "unsubscribe freebsd-java" in the body of the message

Want to link to this message? Use this URL: <>