Adds the --server argument to lldb-server platform which when specified will allow multiple simultaneous connections by forking off to handle each individual connection. This will allow us to run the remote tests in parallel.
I like having a separate process per platform connection. It might be a tiny bit less efficient than a threaded solution but there aren't likely to be a significant number of platform connections and it provides isolation in the event of a crash in platform.
Are you collecting child zombies somewhere?
I think that --daemon might replace --stay-alive. What do you think?
const bool children_inherit_listen_socket = false;
const bool children_inherit_accept_socket = true;
Please take another look, thanks.
For most purposes, I'm sure it does. I was thinking that you might want to debug platform (i.e. not have to worry about forked processes) over multiple runs but I can't imagine any scenario where that would be necessary. Removed stay-alive.
Correct me if I'm mistaken, but doesn't daemon imply that the process runs in the background, whereas in this case the main (listening) process still runs interactively.
Hi Greg, What do you think about this? supporting multiple connections to lldb-platform will allow us to trivially run the test suite in parallel which is going to be incredibly important to us testing against 6 remote Linux architectures and 6 remote Android architectures.
Do we want the have one thread that listens for incoming connections, and once a connection is made, make a new GDBRemoteCommunicationServerPlatform shared pointer and launch a new thread that would communicate over the newly bound port? Then we could have multiple connections to the same lldb-server that could be independent.
Currently this is just a cleanup of the --stay-alive option renaming it to --server. Do we want to take the extra step of allowing multiple simultaneous connections where each connection runs on its own thread? Each GDBRemoteCommunicationServerPlatform object would contain its own state (current working directory, etc).
The key change in this patch is a call to fork() (line 288) to create a new process to handle each connection. The do/while continues on the parent (line 291) immediately listens for new connections (without ever closing the listen socket) while the child process inherits the accepted socket (children_inherit_accept_socket == true), handling it with GDBRemoteCommunicationPlatform and then terminates.
The parent process can then accept as many new connections as it wants forking off a new child process to handle each one.
Gotcha. Separate processes are ok as long as there are no race conditions between two GDBRemoteCommunicationServerPlatform instances in different processes. I don't believe we currently have any caches or any other data we store in a temporary cache, so I believe this is ok. If we ever have some cache that more than one instance of GDBRemoteCommunicationServerPlatform would like to use, we might want to then keep the GDBRemoteCommunicationServerPlatform instances in a single process so they can coordinate more easily. But this should do just fine.