Re: xPL-Issue

[Gerry Duprey <gerry@xxxxxxxxxxx>]

To add my two cents in:

One thing I see with the auto-hub stuff (which I like in principle) is that
when the hub is auto-started, it is always in the same process space of the
app that started it (at least as far as I can tell from looking at the
process lists).

That means when the app that started it terminates, the hub goes away too.
Consider you start an app (like xPLHALMgr) that starts a hub,then you run
another xPL app that sees there is a hub and uses it, then for some reason
later, you stop xPLHALMgr and the hub is gone.  The other xPL app is left
high and dry with no hub.

What I suspect might be a better approach would be for the app that decides
to start a hub to spawn that hub off in a separate process.  Then the hubs
lifecycle is independent of the app that launched it.

The thing I like about this is that auto-starting a hub is a convenience
for
the end user, but doesn't tie them into keeping the initiating app running
indefinitely.

I think that auto-start hubs really are beneficial to most end users who
are
going to find getting xPL apps running more complex than they are used to
anyway. Making them insure that the boot order starts a hub before any xPL
apps seems like it will be error prone to me.

This does not preclude a separate, rock solid hub implementation.  You
could
remove the hub code from the xPL framework and replace it with the ability
to launch/spawn the rock solid hub automatically at startup, if needed.

As for the mutex thing -- could someone summarize why that is done vs. just
using a "port detection" scheme (i.e. see if anything is using
the xPL main
port and if not, start and hub and if so, use the hub).  The mutex is going
to be much more O/S dependent and for those of us creating multi-platform
xPL stuff, it's generally inaccessible (whereas the port in use detection
seems to work everywhere as far as my testing has shown thus far).

Gerry

--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org