This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

why I was seeing exceptions thrown across threads -- a detailed explanation



Andrew Haley <aph@cambridge.redhat.com> writes:
> I'm not sure if I understand what the problem was.  Is it that gcc
> and/or mingw were configured in an incorrect or incompatible way?

I don't fully understand what the functions in gthr-* I was mucking
with do (I've asked gcc@gcc.gnu.org for an explanation), but basically
during the gthreads initialization process, gthreads thought that
thread-local storage was not supported on that platform. Disabling
mingw's "magic extern int" caused it to use a different code path to
check if TLS was available (which it was).

The crummy part is that there seems to be no error checking when
storing to TLS if it is not supported -- it just uses global storage
instead of thread-local storage. Since the jmp_buf's for sjlj
exceptions live in TLS, and gthreads was using a single jmp_buf
instead of one per thread, every setjmp() would obliterate the jmp_buf
of all the other threads. So you'd throw an exception in one thread,
and it would get caught in another (well, not really, but it would be
using the other thread's stack, so it would "look like" it was the
other thread).

Yes, this was really, really painful to debug.

There are a lot of things like this I see where I sorta wish people
would have coded very-inefficient-but-correct fallback cases (like
using a hash table keyed on the address of the bottom of the stack to
simulate TLS, or something like that).

Kinda like GCJ's normal-sync vs hash-sync -- if hash-sync doesn't
work on your platform, there's a fallback (extra pointer in every
object) that will always work.

I've been toying with the idea of doing stuff like this for threads
(assuming you can arrange for the OS can send you a signal or
interrupt every n milliseconds, which should be possible even on DOS
or PalmOS). The neat part about this is it gets you "up and running"
with a new port very quickly, and then your only concern is improving
performance by coding replacements for the fallback implementations.

  - a


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]