Searched +hist:6 +hist:bfd06d1 (Results 1 - 8 of 8) sorted by relevance

/haiku/headers/private/app/
H A DRosterPrivate.hdiff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1ff129f4db4445b978fa3ee9257f239c9 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A DRegistrarDefs.hdiff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6de29761 Fri Nov 08 01:38:50 MST 2002 Tyler Dauwalder <tylerdauwalder@nowhere.fake> Added Load/Save Recent Lists constants


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@1881 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1ff129f4db4445b978fa3ee9257f239c9 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6de29761ece530d4a36faf620b633afaae4b83fc Fri Nov 08 01:38:50 MST 2002 Tyler Dauwalder <tylerdauwalder@nowhere.fake> Added Load/Save Recent Lists constants


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@1881 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/servers/registrar/
H A DTRoster.hdiff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6b454d97 Thu Jul 07 09:33:20 MDT 2005 Ingo Weinhold <ingo_weinhold@gmx.de> * Background applications are now ask to quit in parallel.
* Implemented handling of apps blocking on modal windows.
* Fixed a few bugs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13539 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1ff129f4db4445b978fa3ee9257f239c9 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6b454d971de0b410c4194a1eea853d99be4321cc Thu Jul 07 09:33:20 MDT 2005 Ingo Weinhold <ingo_weinhold@gmx.de> * Background applications are now ask to quit in parallel.
* Implemented handling of apps blocking on modal windows.
* Fixed a few bugs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13539 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A DRegistrar.cppdiff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6b454d97 Thu Jul 07 09:33:20 MDT 2005 Ingo Weinhold <ingo_weinhold@gmx.de> * Background applications are now ask to quit in parallel.
* Implemented handling of apps blocking on modal windows.
* Fixed a few bugs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13539 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1ff129f4db4445b978fa3ee9257f239c9 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6b454d971de0b410c4194a1eea853d99be4321cc Thu Jul 07 09:33:20 MDT 2005 Ingo Weinhold <ingo_weinhold@gmx.de> * Background applications are now ask to quit in parallel.
* Implemented handling of apps blocking on modal windows.
* Fixed a few bugs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13539 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A DTRoster.cppdiff 6ba5fa4d Fri Dec 09 07:25:56 MST 2011 Michael Lotz <mmlr@mlotz.ch> Ensure 0 termination of the buffer being converted to a string.

The file content isn't normally 0 terminated, so making a string out of
it would usually result in reading beyond the allocated buffer to find
the string length, possibly leading to a crash.
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6b454d97 Thu Jul 07 09:33:20 MDT 2005 Ingo Weinhold <ingo_weinhold@gmx.de> * Background applications are now ask to quit in parallel.
* Implemented handling of apps blocking on modal windows.
* Fixed a few bugs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13539 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6ba5fa4d64c5cdda19404c9d8360d809d9546144 Fri Dec 09 07:25:56 MST 2011 Michael Lotz <mmlr@mlotz.ch> Ensure 0 termination of the buffer being converted to a string.

The file content isn't normally 0 terminated, so making a string out of
it would usually result in reading beyond the allocated buffer to find
the string length, possibly leading to a crash.
diff 6bfd06d1ff129f4db4445b978fa3ee9257f239c9 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6b454d971de0b410c4194a1eea853d99be4321cc Thu Jul 07 09:33:20 MDT 2005 Ingo Weinhold <ingo_weinhold@gmx.de> * Background applications are now ask to quit in parallel.
* Implemented handling of apps blocking on modal windows.
* Fixed a few bugs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13539 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/headers/os/app/
H A DRoster.hdiff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1ff129f4db4445b978fa3ee9257f239c9 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/kits/app/
H A DRoster.cppdiff 6faf979d Sat Aug 24 06:42:17 MDT 2019 Adrien Destugues <pulkomandy@pulkomandy.tk> BRoster: Fix infinite loop when trying to launch app with missing libraries.

Fixes #14986.

Change-Id: I727fde0c475f0684567a46be5af616cad56a9b4c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1738
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff 6e1c9c64 Tue Apr 27 11:51:11 MDT 2010 Stephan Aßmus <superstippi@gmx.de> Adjusted the resolving algorithm such that when the preferred handler of the
super type is among the handlers with direct support for the sub-type, that this
handler is at the beginning of the list of fall-back handlers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36507 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6e1c9c648a431226d248b7163afd18ae0fdd6273 Tue Apr 27 11:51:11 MDT 2010 Stephan Aßmus <superstippi@gmx.de> Adjusted the resolving algorithm such that when the preferred handler of the
super type is among the handlers with direct support for the sub-type, that this
handler is at the beginning of the list of fall-back handlers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36507 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1ff129f4db4445b978fa3ee9257f239c9 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A DApplication.cppdiff 6c40fc5d Sat Jan 21 19:06:34 MST 2012 czeidler <haiku@clemens-zeidler.de> Reconnect BApplication and trigger reconnect of all BWindows in an application.
* handle bitmap reconnect request in the app server
diff 6eb09230 Sun Feb 01 15:12:55 MST 2009 Michael Lotz <mmlr@mlotz.ch> * Resolve further warnings on GCC4.
* Enable -Werror on GCC4 builds as well (limited to the same selected targets).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29118 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6d5488e1 Tue Apr 25 14:12:06 MDT 2006 Axel Dörfler <axeld@pinc-software.de> * There is now a server_read_only_memory structure that is placed in a (surprise!)
read-only area shared between the Desktop and all applications.
* Right now, this area only contains the desktop colors, ie. B_PANEL_BACKGROUND_COLOR
etc.; ui_color() no longer needs to ask the server for these colors.
* The ui_colors are now maintained by DesktopSettings, though ColorSet is still there.
* The default colors are now hardcoded once and for everyone in InterfaceDefs.h, ie.
the app_server uses them as well.
* Desktop::Init() can now also return an error (but that is not yet accounted for).
* Cleaned up InterfaceDefs.h.
* Fixed wrong include in moreUTF8.h.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17232 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6cd5d5b1 Tue Jul 27 00:26:07 MDT 2004 Stefano Ceccherini <stefano.ceccherini@gmail.com> Implemented AppResources() "by the book" (not tested), InitialWorkspace(), researched and implemented a TODO item, some small cleanups.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8481 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6c40fc5dfcd03d69d585754505e6b17287a42082 Sat Jan 21 19:06:34 MST 2012 czeidler <haiku@clemens-zeidler.de> Reconnect BApplication and trigger reconnect of all BWindows in an application.
* handle bitmap reconnect request in the app server
diff 6eb09230bae52bcdf045e1f1920b67205c29adc8 Sun Feb 01 15:12:55 MST 2009 Michael Lotz <mmlr@mlotz.ch> * Resolve further warnings on GCC4.
* Enable -Werror on GCC4 builds as well (limited to the same selected targets).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29118 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bfd06d1ff129f4db4445b978fa3ee9257f239c9 Thu Aug 31 11:54:16 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> BRoster::Launch() eventually launches the application in question
in several steps:
1. early pre-registration with the registrar ("I wanna launch the
app, make sure noone interferes.")
2. load the app image
3. finish pre-registration with the registrar ("I have launched
the app, here is its team ID.")
4. start app main thread
5. send "on launch" messages to the app (argv, refs, others)

If the app is already running or being launched, 1. fails with a
conclusive error code and returns the team ID and the pre-registration
token of the app. Steps 2 - 4 are skipped and only the messages are
delivered using the team ID returned by 1.

This change fixes a race condition: The failed early pre-registration
request obviously cannot return the team ID, if the other thread
launching the app has not finished step 3 yet. Thus the argv/refs
message would not get delivered and Launch() would not return the
correct team ID.

Now we wait for the pre-registration to be finished in this case, using
the former _IsAppPreRegistered() mechanism, which already provided
such a waiting feature for one request. It has been extended to
accomodate an arbitrary number of waiting requests and renamed to
_IsAppRegistered().

This fixed bug #763.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18728 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6d5488e18ac47e1c47706227b9a21524ae7874e8 Tue Apr 25 14:12:06 MDT 2006 Axel Dörfler <axeld@pinc-software.de> * There is now a server_read_only_memory structure that is placed in a (surprise!)
read-only area shared between the Desktop and all applications.
* Right now, this area only contains the desktop colors, ie. B_PANEL_BACKGROUND_COLOR
etc.; ui_color() no longer needs to ask the server for these colors.
* The ui_colors are now maintained by DesktopSettings, though ColorSet is still there.
* The default colors are now hardcoded once and for everyone in InterfaceDefs.h, ie.
the app_server uses them as well.
* Desktop::Init() can now also return an error (but that is not yet accounted for).
* Cleaned up InterfaceDefs.h.
* Fixed wrong include in moreUTF8.h.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17232 a95241bf-73f2-0310-859d-f6bbb57e9c96

Completed in 360 milliseconds