linux/poky.git/bitbake/lib/bb/asyncrpc, branch yocto-4.0.19

bitbake: asyncrpc: Add context manager API

2024-01-10T15:14:16+00:00

Adds context manager API for the asyncrcp client class which allow writing code that will automatically close the connection like so: with hashserv.create_client(address) as client: ... Rework the bitbake-hashclient tool and PR server to use this new API to fix warnings about unclosed event loops when exiting (Bitbake rev: ee090484cc25d760b8c20f18add17b5eff485b40) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie (cherry picked from commit d01d684a0f6398270fe35ed59b7d28f3fd9b7e41) Signed-off-by: Steve Sakoman

bitbake: asyncrpc/client: Fix unix domain socket chdir race issues

2022-10-11T20:57:28+00:00

The connect_unix() call had a bug where if a relative path to a socket was passed (which the non-async client always does), and the current working directory was changed after the initial call, it would fail to reconnect if it became disconnected, since the socket couldn't be found relative to the new current working directory. To work around this, change the socket connection for UNIX domain sockets to be synchronous and change current working before connecting. This isn't ideal since the connection could block the entire event loop, but in practice this shouldn't happen since the socket are local files anyway. Help debugging and resolving from Joshua Watt. (Bitbake rev: 6603c3e39f1cf746669ec6c9f0be8c6e6ece426e) Signed-off-by: Richard Purdie (cherry picked from commit 5964bb67bb20df7f411ee0650cf189504a05cf25) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: bitbake: Add copyright headers where missing

2022-10-11T20:57:28+00:00

Where copyright headers were not present, add them to make things clear. (Bitbake rev: e591325b2bd901c381003deb96a7b32a7148e93e) Signed-off-by: Richard Purdie (cherry picked from commit 1aa338a216350a2751fff52f866039343e9ac013) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: asyncrpc: Fix attribute errors

2022-02-17T17:51:03+00:00

Export ClientError and ServerError classes from bb.asyncrpc.serv as required by lib/hashserv/server.py module. Error: Client ('192.168.2.184', 51142) connected Error from client: module 'bb.asyncrpc' has no attribute 'ClientError' Traceback (most recent call last): File "/opt/bbhashserv/lib/bb/asyncrpc/serv.py", line 192, in handle_client await client.process_requests() File "/opt/bbhashserv/lib/hashserv/server.py", line 200, in process_requests await super().process_requests() File "/opt/bbhashserv/lib/bb/asyncrpc/serv.py", line 72, in process_requests await self.dispatch_message(d) File "/opt/bbhashserv/lib/hashserv/server.py", line 217, in dispatch_message raise bb.asyncrpc.ClientError("Unrecognized command %r" % msg) AttributeError: module 'bb.asyncrpc' has no attribute 'ClientError' (Bitbake rev: 8aca1d341500af8bbe788801c2df3da9bbfacaed) Signed-off-by: Daniel Gomez Signed-off-by: Richard Purdie

bitbake: async: Close sync client event loop

2021-10-11T10:00:06+00:00

Prevents `ResourceWarning: unclosed event loop` warnings when using the synchronous client and python exits (Bitbake rev: 8b95972bc04ce52a98c7780184af15a5e95f987b) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: bitbake: asyncrpc: always create new asyncio loops

2021-08-23T07:30:54+00:00

asyncio in older Python 3.x (seen with 3.7) can seemingly hang if new_event_loop is called repeatedly in the same process. The reuse of processes in the Bitbake thread pool during parsing seems to be able to trigger this with the PR server export selftest. It appears that calling set_event_loop with the new loop avoids the issue, so that is now done in the asyncrpc Client initializer (with an explanatory comment). This should be revisited when the day arrives that Python 3.9 becomes the minimum required for BitBake. Additionally, it was discovered that using get_event_loop in the asyncrpc server initialization can trigger hangs in the hashserv unittests when the second test is run. To avoid this, switch to calling new_event_loop + set_event_loop in the initialization code there as well. (Bitbake rev: bb9a36563505652294b20b4c88199b24fa208342) Signed-off-by: Scott Murray Signed-off-by: Richard Purdie

bitbake: bitbake: asyncrpc: Defer all asyncio to child process

2021-08-23T07:30:54+00:00

Reworks the async I/O API so that the async loop is only created in the child process. This requires deferring the creation of the server until the child process and a queue to transfer the bound address back to the parent process (Bitbake rev: 8555869cde39f9e9a9ced5a3e5788209640f6d50) Signed-off-by: Joshua Watt [small loop -> self.loop fix in serv.py] Signed-off-by: Scott Murray Signed-off-by: Richard Purdie

bitbake: bitbake: asyncrpc: Catch early SIGTERM

2021-07-29T22:21:24+00:00

If the SIGTERM signal is sent to an asyncrpc server before it has installed the SIGTERM handler in the main loop, it may miss the signal which will can cause the calling process to wait forever on the join(). To resolve this, the calling process should mask of SIGTERM before forking the server process and the server should unmask the signal only after the handler is installed. To simplify the usage of the server, an new helper function called serve_as_process() is added to do this automatically and correctly. Thanks: Scott Murray for helping debug (Bitbake rev: ef2865efa98ad20823267364f2159d8d8c931400) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: asyncrpc: Set timeout when waiting for reply from server

2021-07-29T22:21:24+00:00

(Bitbake rev: b31f1853d7fcb8b8f8885ca513a0021a5d0301e6) Signed-off-by: Paul Barker Signed-off-by: Richard Purdie

bitbake: asyncrpc: Fix bad message error in client

2021-07-29T22:21:24+00:00

If there is an issue with the format of the reply given by the server then we should print this reply line in the error message. Printing the message which the client sent doesn't illuminate anything here. (Bitbake rev: bd8f8d7b055da15cd7bdd0b383061852a0f54cb7) Signed-off-by: Paul Barker Signed-off-by: Richard Purdie