> 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?
That is one reason (these multival returns are really quite awkward and tedious). But for process[*], the I/O ports are clearly properties of the process and need to be made available and associated with the process. I can't come up with a cleaner way to obtain these ports. > 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. I suggest to set those slots to #f in all other process-creation operations, indicating no associated ports. > 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). I guess the global table is the simplest method then (I assume the table can be reset to '() in any forked child process). "process-fork", "*-spawn" and "*-run" can also return a process object, keeping uses more or less transparent. Of course if we create lots of processes and never wait, then the table will grow, as we do no auto-reaping (Scsh does this, IIRC). > > PS: It'd also make sense to have process-signal accept process objects. Yes, that makes sense. felix
