harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Rogers <ian.rog...@manchester.ac.uk>
Subject The state of signal portability
Date Fri, 06 Mar 2009 15:15:22 GMT
Hi,

I'm in the process of trying to make a VM run using the Harmony class
libraries and I'm having some trouble with portlib when I need to implement
signals. In the hyport header there are still routines relating to signal
handling, but looking into the portlib code they have no implementation. I
believe all signal handling code from portlib was removed prior to M8.
Looking around for inspiration I believe the situation is:

1) IBM VMEs use Harmony's portlib and then implements threads and signal
handling using services available from the host OS, the thread services are
exported back to Harmony via hythr.so

2) DRLVM in part uses the Harmony porting layer, in part uses Apache
Portable Runtime (APR) and in part uses services from the host OS

Using APR is tempting, but as it doesn't underly the Harmony portlib it
seems to lead to a mismatch with APR managing somethings and Harmony others
(ie. who allocates data structures for signal handlers APR using an APR
memory pool or Harmony using its). Of course I could rewrite the portlib
using APR, but this is a lot of work. The reserve/commit virtual memory
routines in portlib are also not reflected in APR.

What I'd like is for each service I need for the VM to be wrapped up in a
portable way. I'd naively assumed portlib did this, which it does except for
signal handling. I'd like to avoid maintaining thread and signal libraries
for all architecture and OS combinations. Harmony's portlib doesn't contain
a solution for signals, APR does contain a solution but doesn't appear to
fit into the Harmony eco-system correctly. I'm left with mixing Harmony's
thread implementation with bespoke signal handler implementations, perhaps
the cleanest and easiest way for me to get these is from a M7 version of the
portlib.

Has anybody else found a sensible way to avoid this pain?

Thanks,
Ian Rogers

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message