RE: xPL-Issue

["John B" <home-automation@xxxxxxxxxxxxxxxx>]

Hi,

> 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.

That's correct.

> 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.

No it's not - that's where the mutex comes in.

As soon as the app that's acting as the hub closes, it releases it's
mutex.  Even if it crashes, Windows will still release the mutex.

Meanwhile, every other running app that is V3-hub aware will have been
sat there with a wait request to receive ownership of the mutex.
So, as soon as the mutex is released, another app will grab it and the
hub will take over.

> 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.

But this raises all sorts of problems for services - if a service fires
off a hub in a separate process, it will still be killed by the OS when
the service is stopped.

>
> 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.

I agree - and if we do have issues with the current situation with
regards to the new V3-style hubs, we should at least figure out the root
cause of any issues before making any decisions as to their suitability.

I for one have been using a mixture of V2, V3 and OCX-based apps on a
number of different systems ever since the early days of V3, and I've
never had a hub problem.

>
> 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.

But then you're back to having to distribute the rock-solid hub - and
every app would need to install/detect whether this rock-solid hub was
already present.

I like the idea of every app having it's own hub built-in - no other
software is required to get the user up and running.

> 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).

Port detection is fine for detecting a hub when your app starts.
But suppose another hub is already running. You're going to have to keep
polling the port just in case the hub goes down - as you need to take
over as quickly as possible.

If you have lots of xPL apps running on the host at once, you're going
to have a lot of socket calls going on all the time, which IMO is not a
very efficient way of doing things.

> 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).

If you can't access mutexes from Java (I'd be surprised if there wasn't
some way of gaining access to mutexes, as just about every OS uses them
for process synchronisation and IPC), then go with the port detection
scheme. Your apps will still sit fine with other apps that do use the
mutex - it's just that the transfer of hub functionality from one to the
other won't be as quick.

Regards,

John