linux/poky.git/bitbake/lib/bb/server/process.py, branch dizzy-12.0.1

bitbake: process: Ensure abnormal exits set an error level

2014-09-02T17:10:37+00:00

(Bitbake rev: 8f5c1cdae1ee6ce04ae0d04d0b95bd80efbf7534) Signed-off-by: Richard Purdie

bitbake: process: Further improve robustness against server shutdown

2014-08-23T08:31:42+00:00

Currently, if an exception occurs in an event handler, the server shuts down but the UI simply hangs. This happens in two places, firstly waiting for events and secondly, sending events to a server which no longer exists. The latter does time out, the former does not. These patches improve both code sections to check if the main server process is alive and if not, trigger things to shut down gracefully. This avoids the timeout in the command sending case too. This resolves various cases where the UI would simply hang indefintely. (Bitbake rev: ac418e1112ff5f9c3157569316902f7a27fba4b4) Signed-off-by: Richard Purdie

bitbake: process: Deal with infinite looping of the server

2014-08-23T08:31:42+00:00

Currently if an exception occurs, we just run the idle handler again and again, usually looping indefintely. Chances are the exception that occurred will keep occuring and this is not a good place to be. This was breaking the autobuilders with gigabytes of logs. At least improve things so the cooker shuts down gracefully when this happens. Some trace of the original problem may still be present on the console too! (Bitbake rev: 1f28d8d3311262427938180435b68f0a35c2b330) Signed-off-by: Richard Purdie

bitbake: server/process: Optimise latency when finishing idle functions

2014-03-10T18:10:02+00:00

When idle functions finish, its likely we have some other work to do, so don't sleep in the select call but instead, skip it. This removes small amounts of latency in common commands. (Bitbake rev: 069d6538f83b607cb46c6fe21bf6c596e8b99242) Signed-off-by: Richard Purdie

bitbake: server/process: Drop unnecessary exit delay

2014-03-10T18:10:01+00:00

When the server exits, we no longer appear to need this delay. This is likely due to improvements in the various exit codepaths. There is therefore no longer any point in taking the latency hit. (Bitbake rev: 8e75ee29ae07e13f23525c5c6045fbf6cdbe7675) Signed-off-by: Richard Purdie

bitbake: server/process: Use a pipe for quit events instead of Event()

2014-03-10T18:10:01+00:00

Its not possible to notice the change of status of an Event() in the select call we sleep in. It would be possible in python 3.3 but for now use a pipe instead. This removes small latency when bitbake commands finish since the system doesn't sit in the select call. (Debugging these kind of issues is apparent by setting a long sleep for the select call) (Bitbake rev: def28239b0f0d5f1cf13214b263114a5328538b7) Signed-off-by: Richard Purdie

bitbake: server/process: Deal more gracefully with SIGTERM

2014-03-10T18:09:59+00:00

Currently a SIGTERM to the UI process causes the UI simply to lock up. By setting an exit flag, the waitEvent can raise a SIGINT, allowing the UI to break out the event loop and exit. Currently this is results in a traceback but that is more desirable than a hanging process. (Bitbake rev: 0d12041eceeae6bba2034b04913bb13abd67bd15) Signed-off-by: Richard Purdie

bitbake: server/process: Use the setFeatures command on the server instead of a manger

2014-03-10T18:09:59+00:00

The use of a manager in the process server causes some issues since it remains around for the lifetime of the server even though its only used during initialisation and the system doesn't respond well to SIGTERM events to the extra process (and two threads) the implementation involves. Switching to a dedicated command simplifies the server process structure. (Bitbake rev: 74532a7cf8ccea8b85f1cda5d5bc23d2f3c72a08) Signed-off-by: Richard Purdie

bitbake: bitbake: cooker,xmlrpc,servers: implement CookerFeatures

2013-09-22T11:19:43+00:00

Implementing feature set selection that allows a client to enable specific features in the server at connection time. Only enabling of features is supported, as there is no way to safely remove data loaded into the cooker. Once enabled, a feature will remain enabled for the life of the cooker. Client-server connection now supports specifying the feature set required by the client. This is implemented in the Process server using a managed proxy list, so the server cooker will now load dynamically needed features based on what client connects to it. In the XMLRPC server the feature set is requested by using a parameter for registerUIHandler function. This allows observer-only clients to also specify features for the server. The server code configuration now is completly separated from the client code. All hardcoding of client knowledge is removed from the server. The extra_caches is removed as the client can now specify the caches it needs using the feature. The UI modules now need to specify the desired featureSet. HOB is modified to conform to the featureSet specification. The only feature available is CookerFeatures.HOB_EXTRA_CACHES which forces loading the bb.cache_extra:HobRecipeInfo class. (Bitbake rev: 98e594837aab89ea042cfa9f3740d20a661b14e2) Signed-off-by: Alexandru DAMIAN Signed-off-by: Richard Purdie

bitbake: cooker: Rename confusing 'stop' state to 'forceshutdown'

2013-09-14T07:20:38+00:00

The shutdown state causes the server to finish what its doing, stop was them meant to completely stop it. It doesn't mean the server is stopped though. Renaming the current stop event for forceshutdown gives more meaning to what it actually does. The stopped namespace then becomes available to indicate a completely stopped server. (Bitbake rev: 12e9d33bfae5294e3870dfd1202f63383ad05e92) Signed-off-by: Richard Purdie