Reply with the group process's PID after a request

This commit is contained in:
Robbert van der Helm
2020-05-22 14:28:25 +02:00
parent dd843519ce
commit 9b50bac179
2 changed files with 21 additions and 8 deletions
+15
View File
@@ -598,3 +598,18 @@ struct std::hash<GroupRequest> {
return hasher(params.plugin_path) ^ (hasher(params.socket_path) << 1);
}
};
/**
* The response sent back after the group host process receives a `GroupRequest`
* object. This only holds the group process's PID because we need to know if
* the group process crashes while it is initializing the plugin to prevent us
* from waiting indefinitely for the socket to be connected to.
*/
struct GroupResponse {
int pid;
template <typename S>
void serialize(S& s) {
s.value4b(pid);
}
};
+6 -8
View File
@@ -18,6 +18,7 @@
#include <unistd.h>
#include <boost/asio/read_until.hpp>
#include <boost/process/environment.hpp>
#include <regex>
#include "../../common/communication.h"
@@ -135,15 +136,12 @@ void GroupBridge::accept_requests() {
// Read the parameters, and then host the plugin in this process
// just like if we would be hosting the plugin individually through
// `yabridge-hsot.exe`. Since we're using sockets there's no reason
// to send an acknowledgement back. One potential issue here is that
// it will be hard to tell whether a plugin has crashed before
// initialization, and that the sockets will never be accepted. For
// individually hosted plugins we poll whether the Wine process is
// still active so we can terminate early if it is not, but in this
// case the yabridge instance has to determine that this process is
// still running.
// `yabridge-hsot.exe`. We will reply with this process's PID so the
// yabridge plugin will be able to tell if the plugin has caused
// this process to crash during its initialization to prevent
// waiting indefinitely on the sockets to be connected to.
const auto parameters = read_object<GroupRequest>(socket);
write_object(socket, GroupResponse{boost::this_process::get_id()});
// Collisions in the generated socket names should be very rare, but
// it could in theory happen