[interfacekit] Re: BRoster

> > Has anyone already thought about how to deal with single/multi 
> > launch
> > applications? I currently have no concrete idea. 
> 
> Ignoring you question for the moment :-), do even know of any 
> examples of 
> B_MULTIPLE_LAUNCH or B_EXCLUSIVE_LAUNCH programs? Unless I'm looking 
> in the 
> wrong place (which I may be :-) -- it's the BEOS:APP_FLAGS attribute 
> of the 
> executable, isn't it?), every app I've looked at so far has been 
> B_SINGLE_LAUNCH. Not that we couldn't make our own for testing, 
> but...

Mmh, I don't know of any in BeOS itself, though I think for a lot of 
daemons (e.g. the registrar itself), this would make sense. 
B_MULTIPLE_LAUNCH is useful for command line applications using a 
feature that requires a BApplication (e.g. BBitmap).

> > Somehow this must be done in the (early?) registration phase, 
> > I guess. I'm not sure though.
> 
> It seems to me it would need to be handled even before the 
> application was 
> launched. I'm perhaps naively assuming that BRoster::Launch() is the 
> only 
> application launch point in the whole system (load_image() aside, 
> which I 
> assume would only be used in special circumstances, and further would 
> not 
> be concerned with B_*_LAUNCH flags). 

In fact there is even another way to launch an application: exec*(). 
And I think regardless of how an application is launched the B_*_LAUNCH 
flags should always be respected.

Anyway, I tested how BeOS handles this, and I found out, that when 
starting an already running single/exclusive launch app the second 
time, main() is called as usual, but the BApplication constructor 
exit()s.

> My first guess would be that the registrar has a list of running (and 
> registered?) applications, with an app_info struct (or something 
> similar) 
> for each.

No doubt, it has such a list. :-P

> When BRoster::Launch(), or more likely 
> BRoster::xLaunchAppPrivate(), gets called, it would do the following:
>  
> + B_MULTIPLE_LAUNCH -- Just launch away no matter what. 
> + B_SINGLE_LAUNCH -- Ask the registrar if any of the running apps has 
> an 
> app_info::ref field that matches that of the executable you're 
> considering 
> launching. If so, don't launch and send the launch messages to the 
> already 
> running app; if not, launch. 
> + B_EXCLUSIVE_LAUNCH -- Same thing as B_SINGLE_LAUNCH, but check 
> app_info::signature instead.

I agree with the strategy in principle, but not with the place where it 
is applied (as I pointed out above). I think the question is only 
where, in the BApplication constructor or in the roster? And currently 
I tend towards the roster, since it must make the final decision 
anyway. Just think of one application launched twice in parallel -- 
both will ask whether an instance of their application is already 
running and will be told "no".

I think the BApplication constructor should gather all information 
needed (signature, entry_ref, app flags,..., argv) and send a 
registration request to the roster (quite similar to 
BRoster::AddApplication()). The roster decides whether the application 
is allowed to start up and fulfills/denies the request accordingly. On 
denial it sends a B_ARGV_RECEIVED to the already running application 
and the new application exit()s.

CU, Ingo

Other related posts: