On Tue, Dec 31, 2024 at 11:39:12AM +0100, [email protected] wrote: > This is an attempt to fix #766. "process" and "process*" return a structure > holding > the process ports, exit status, pid, etc. Accessors for these slots are > provided. > "process-wait" accepts either a pid or a process object. This is somewhat > nicer > than returning a bunch of values and also allows retrieving the exit status > even > if the child was already waited upon as ports were closed.
I've been thinking a bit about this and I'm not 100% sure it makes sense to also store the process ports in the structure. There's no real need to have them available there. I think we're only doing this so that process-run can return a single value instead of multiple values, right? IMO, the main reason to have process objects is so you can wait for them multiple times, and can get the exit status even if it's exited long ago. Finally, for scsh-process to make use of this new process object, we also need process-fork (and logically, probably also process-spawn) to return process objects. If we want to keep the ports in the process objects, for process-fork we could use the values of current-*-port, but I'm not sure how that goes for spawn. Also, if those ports have been rebound, I don't think this will work correctly. All in all, I think this is a good reason to drop these values from the process object. Note that the venerable scsh itself also didn't have anything aside from a pid exposed from these objects: https://scsh.net/docu/html/man-Z-H-4.html#node_sec_3.4.1 There's one more problem: calling process-wait without arguments will wait for the "next" child to exit. This provides a way to accidentally bypass the mechanism that fills in the exit status slot for the process in question and means you cannot safely call it like that because it will break this mechanism if the "wrong" process exits. Also, waiting for a process by pid will do the same. I see two ways around this: the first would be to simply disallow waiting for "any" child, the second would be to have a global table mapping pid to process objects so that we can update the corresponding process' status (both scsh-process and SCSH do the latter, but it's somewhat ugly and slow, but at least it's safe and means it also allows safely waiting for pid by integer). PS: It'd also make sense to have process-signal accept process objects. Cheers, Peter
