On Thu 14 Jul 2016 17:34, Eli Zaretskii <e...@gnu.org> writes: >> > The process ID is indeed an int, but my code hides a process handle >> > inside it. >> >> If you don't mind my asking: why? :) > > Because that's the only way on Windows to make sure the process object > is kept around by the kernel. Integer PIDs are reused very quickly on > Windows, so by the time you get to scm_waitpid or some other function > that wants to query the process, that PID might not exist, or even > name a different process. Having a handle open on the process > prevents the process object from being recycled. Also, _cwait, used > by the Windows emulation of waitpid, needs a handle.
Are you saying that Windows doesn't wait until you waitpid() on a PID to reap it? >> The caller effectively just returns the PID to Scheme, at which >> point it has a not-quite-PID floating around. Sounds like trouble >> to me. > > Not sure why you think it's trouble. Can you explain? Just that spawn_child isn't the only way to get a PID. getpid would be the most obvious one, but reading a PID value over a socket or whatever is also possible. But then your code is now introducing not-quite-PIDs as well. What if an interface expects one but gets the other? Andy