|
00:05
Voldenet_ joined
00:06
Voldenet left,
Voldenet_ is now known as Voldenet
00:07
japhb joined
04:32
sena_kun joined
08:39
sena_kun left
11:29
sena_kun joined
15:49
nine left,
nine joined
16:37
notna joined
17:20
notna left
|
|||
| patrickb | timo: My first inuition would have been to explicitly pass down debug server connection information from the parent process to the child and then bring up a new connection to that new child. | 19:47 | |
| timo | yeah, but usually the user's raku code is responsible for building the commandline for execing | ||
| patrickb | Hm. Interesting problem. | 19:48 | |
| There is no way to determine the actual executable that will be run given some command line, right? | 19:49 | ||
| Shell can be involved and path resolution plays into it as well. | 19:50 | ||
| Tinkering a tiniest bit with the environment would be enough to get the info passed on. (Like adding a cryptic env var with connection info) The child moar process could routinely check for such an env var. | 19:51 | ||
| timo | how do you mean "routinely"? | 19:52 | |
| patrickb | Like on every start unconditionally. | 20:07 | |
| Actually I think this is not such a bad idea after all. We can make the behavior optional (--debug-pass-to-child or some such) and then shortly explain how the magic happens. | 20:08 | ||
| timo | i think the choice to give commandline args instead of env vars may have been deliberate? | 20:15 | |
| patrickb | I'd say command line arg (just like the other debug args) to enable the mode, but an env var to pass state down to potential children. | 21:07 | |
| env vars have a much higher chance to not mess up the program being called and to survive indirections like shell scripts | 21:08 | ||
| And then in the parent request a port in the client waiting for connections and pass the connection info down via the env var. | 21:14 | ||
| The child moar process sees the env var, enables the Debugserver and initiates the connection with the client. | 21:15 | ||
| Or maybe even better, tunnel the connection through the initial debugged moar process. Then it'll work nicely in remote debug scenarios as well. | 21:16 | ||
| So the parent opens a port / Unix socket / whatever, and sets MOARVM_DEBUG_CHILD_CONNECTION=38462 | 21:18 | ||
| The child moar notices that env var and tries to establish a connection with the parent process. The parent process then forwards the stuff it receives on that connection to the client. The protocol would need to be extended to allow adding a process identifier to each message. | 21:21 | ||
| There might be some potential security hole as an env var triggers moar to try to establish a network connection. | 21:22 | ||
| CGI sends you their regards... 🤦🏻 | 21:23 | ||
|
21:42
sena_kun left
|
|||