OK to add _STRACE_FORK category?

[Ryan Johnson]

On 10/05/2011 6:09 AM, Corinna Vinschen wrote:
> On May  4 15:33, Ryan Johnson wrote:
>> 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
> I just noticed that I never replied.  Please use sigproc_printf and
> debug_printf.  However, fork has already a lot of strace output, so
> it would be favorable to keep the number of extra printfs as small
> as possible.  Maybe there are even some we should remove.
sigproc_printf: ack.

As for the quantity of output, I'm torn. Whenever Windows throws a new 
curveball at fork() the first step will always be to figure out what new 
thing went wrong (or what existing thing is suddenly going wrong more 
often), and I've added special_printf calls which expose this 
information in a fair amount of detail. Problem is, AFAICT *_printf 
calls execute fully whenever strace is active, with strace performing 
the filtering on its side. This means a lot of unwanted overhead most of 
the time. Perhaps I should leave the calls there, with an #ifdef 
(DEBUGGING?) so future developers don't have to reinvent the wheel next 
time around?

Ryan