[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gnulib] wait-process module
From: |
Bruno Haible |
Subject: |
Re: [bug-gnulib] wait-process module |
Date: |
Wed, 26 Apr 2006 20:15:15 +0200 |
User-agent: |
KMail/1.5 |
Derek,
> I apologize for the misunderstanding. You hadn't replied to new points
> raised by three different people
Noone raised an important change request regarding the wait-process module in
a year.
> and in general the process on GNULIB
> has seemed to me to be that no response meant approval on this list,
> generally after about a week.
This is true regarding modules that you propose on your own, or for likely
uncontroversial changes. Not for changes for which there is doubt or even
a known objection.
But I accept your apologies. Let's talk about the patch.
It adds a new parameter, so that wait_process can inform the caller about
the way the subprocess terminated.
> Anyhow, I understood that your main objection to this patch is that this
> is not portable to Windows, and it _is_ portable to Windows.
When I say that it is _not_ portable to Windows, I mean the following:
If someone writes a program that uses the feature, the feature will not work on
Windows. The 'exitsignal' will always be 0 on Windows, even if the subprocess
died from an illegal instruction or GFP or Ctrl-Break.
The patch compiles on Windows, but that's not the point.
When a gnulib user uses a documented behaviour of a gnulib function and it works
on Linux or Solaris, it should have a reasonable probability of working on
Windows as well. That's the whole point of a "portability library".
> The new code only allows the caller to know that a signal caused the
> child to exit, *when a signal is present*. I really don't understand
> why you think the new code should do something when a signal is not
> present.
Which exitsignal does your patch return when the subprocess on Windows
died from illegal instruction, GFP or Ctrl-Break?
> Would the addition of documentation that mentioned that signals are not
> detected (and therefore never returned) under Windows and why make the
> patch more palatable for you?
If there was no other solution to the problem, yes. But there are more portable
solutions. How about this one:
- The subprocess, as last thing it does in main() before exit(0), sends
to the parent process a bit of information indicating that it succeeded.
This information can take the form of a file that is created or deleted
on the filesystem, or of a particular byte value sent through a file
descriptor to the parent (very easy to do if the subprocess was created
through the pipe() function or equivalent), or similar.
This should be a solution that works portably, no?
Bruno