linux/poky.git/bitbake/lib/bb/server, branch 1.6_M5

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.lock: Add host:port to bitbake.lock for memres server

2013-12-02T17:33:14+00:00

The idea is to build on the --status-only option for bitbake and expose a mechanism where the oe init scripts can easily switch between memres server and the non-memres server. In the case of the standard oe init script the following can shut down the server: if [ -z "$BBSERVER" ] && [ -f bitbake.lock ] ; then grep ":" bitbake.lock > /dev/null && BBSERVER=`cat bitbake.lock` bitbake --status-only if [ $? = 0 ] ; then echo "Shutting down bitbake memory resident server with bitbake -m" BBSERVER=`cat bitbake.lock` bitbake -m fi fi A similar function can be used to automatically detect if the server is already running for the oe memres init script. This new functionality allows for the memres init script to be started in a new shell and connect up to an alaready running server without seeing the error of trying to start the server multiple times. (Bitbake rev: b1803958de8d7c3c3279841e38604a08dc2316cc) Signed-off-by: Jason Wessel Signed-off-by: Richard Purdie

bitbake: bitbake, xmlrpc.py: Implement memory resident auto port configuration/restart

2013-12-02T11:28:27+00:00

This patch adds the ability to dynamically select a port for the bitbake memory resident server when the BBSERVER port is set to -1. This allows for running multiple instances of the bitbake memory resident server on the same system in different build directories. The client portion of the bitbake instance can also request that the server automatically start when using the auto port feature. This is to deal with a bitbake instance that eventually times out and exits or that has died for some unknown reason. The new functionality allows for lazy startup of the server after sourcing the init script for the memory resident functionality. (Bitbake rev: d6abc07ff385357d312d8435b89e0a9c1f965433) Signed-off-by: Jason Wessel Signed-off-by: Richard Purdie

bitbake: xmlrpc: Show a better error message for connection failures

2013-10-07T08:37:34+00:00

Showing a traceback when unable to connect to a bitbake server is rather ugly. This change allows us to show a sensible error message. (Bitbake rev: 26913202f83fbbecdce95da59515af102bcde4a7) 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