Ian, > fit into the Harmony eco-system correctly
I have not caught why APR does not fit into the Harmony eco-system correctly. It really does because all these portability functions are just trivial wrappers for OS calls, and Harmony VM is a living example. I feel from your letter that you like portlib - if you are determined, then I suggest restoring signal functionality from M7 in M8. I would not recommend forking at M7. Open sourcers needed to concentrate their efforts, hence the last version is always the preferable one. Thanks. On Fri, Mar 6, 2009 at 6:15 PM, Ian Rogers <[email protected]> wrote: > 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 > -- С уважением, Алексей Федотов, http://people.apache.org/~aaf/
