OK to add _STRACE_FORK category?

[Ryan Johnson]

Hi all,

I'm currently producing sending quite a bit of information to 
special_printf while forking, and suspect that at least some of it would 
be good to leave in place. Further, I think it would make sense to have 
a fork category for strace so that people trying to diagnose fork 
problems have a way to figure out what's going wrong without having to 
slog through strace's all/debug output:

         thread   0x040000 (_STRACE_THREAD)   Thread-locking calls.
+       fork     0x080000 (_STRACE_FORK)     Fork-related information.
         special  0x100000 (_STRACE_SPECIAL)  Special debugging printfs for
                                              non-checked-in code


If folks are all right seeing an _STRACE_FORK appear, I'll add that to 
my code before submitting a patch and cgf or somebody can decide which 
fork_printf calls to actually keep. Otherwise, I'll submit a patch 
containing special_printf calls and solicit input on which categories 
the "keepers" should live in.

I would actually like to see api_fatal calls from a child process 
diverted to strace_printf if in_forkee=1, since they're quite annoying 
to the user and not usually helpful, but that's a separate discussion. 
For now I have a "fork_api_fatal" call which triggers a clean exit of 
the child, to be used in cases where we know exactly what's wrong but 
can't do anything about it. So far there are three such cases:
(a) static dll mapped to wrong address in the child (no way to unload it 
and retry)
(b) space needed for a dynamic dll already occupied (thread stack, heap, 
locale.nls...)
(c) failure to allocate the child's cygheap

Note that in all three cases, the underlying cause is usually (b).

Thoughts?
Ryan