PreTraceHook, PostTraceHook and ErrorHdrHook hooks in RTS
simonmar at microsoft.com
Tue Feb 10 11:17:01 EST 2004
> My proposal is to replace the hooks:
> void PreTraceHook(long fd);
> void PostTraceHook(long fd);
> void ErrorHdrHook(long fd);
> with the general hooks:
> void TraceHook(char *msg)
> fputs(msg, stderr);
> void ErrorHook(char *msg)
> fprintf(stderr, "Fail: %s", msg);
> I am waiting forward to your comments and proposals.
> If you accept the idea, I will be happy to implement
Let's take these seperately:
(1) ErrorHdrHook: yes. Most of the contents of writeErrString__ (in
libraries/base/cbits/writeError.c) can be replaced by a hook,
which looks like a good idea. This affects the top-level
exception handler for a program and the top-level exception
handler for concurrent threads.
Perhaps on Windows, for a program that is compiled with -mwindows(?)
we should link in a version of ErrorHook that pops up a MessageBox
instead of using stderr (and fix all the other places that the
RTS relies on having stdout/stderr...).
(2) TraceHook: I'm not so sure about this. In my opinion, it's fine
for trace to be defined as outputing to stderr:
trace s e = unsafePerformIO (hPutStr stderr s >> return e)
but an application should use its own version of trace if needs be.
(eg. in GHC we should use our own version of trace which might
use the debug console on Windows). IMO we should get rid of
PreTraceHook and PostTraceHook.
The difference between this and the ErrorHook is that the programmer
has the option to call a different trace, but the programmer
has no control over what's used for the top-level exception handler
in the program, so it makes sense to allow the use of a hook there.
trace shouldn't be used by library code.
More information about the Glasgow-haskell-users