On Montag, 18. Januar 2010, Erik Faye-Lund wrote: > On Sat, Jan 16, 2010 at 10:12 AM, Erik Faye-Lund wrote: > > On Sat, Jan 16, 2010 at 9:03 AM, Johannes Sixt <j6t@xxxxxxxx> wrote: > >> On Freitag, 15. Januar 2010, Erik Faye-Lund wrote: > >>> No. If I do, the pid becomes invalid after the process is finished, > >>> and waitpid won't work. I couldn't find anywhere were we actually were > >>> closing the handle, even after it was finished. So I don't think we > >>> leak any more than we already did (for non-daemon purposes). > >> > >> Previously, this handle was closed by _cwait() (it was the "pid"), so we > >> didn't leak it. > > > > Oh, I see. My planned route with this (before I looked for where the > > handle was closed), was to maintain some sort of list of each started > > PID and their handle, and lookup in that list instead of using > > OpenProcess. I guess that would solve the problem here, but it feels a > > bit nasty. Not as nasty as introducing a leak, though. > > What I had in mind was something along these lines: Given that that the process ID is the user-visible (and system-wide unique) identifier of a process, this looks like the only reasonable way to go. Your implementation looks good as well. > + /* store process handle */ /* * The process ID is the human-readable identifier of the process * that we want to present in log and error messages. The handle * is not useful for this purpose. But we cannot close it, either, * because it is not possible to turn a process ID into a process * handle after the process terminated. * Keep the handle in a list for waitpid. */ > + num_pinfo++; > + pinfo = xrealloc(pinfo, sizeof(struct pid_info) * num_pinfo); > + pinfo[num_pinfo - 1].pid = pi.dwProcessId; > + pinfo[num_pinfo - 1].proc = pi.hProcess; > + > return (pid_t)pi.dwProcessId; -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html