[m-dev.] for review: subdivision of mercury_trace.c

[Fergus Henderson]

On 16-Apr-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> > We haven't really thought about how tracing interacts with multi-
> > threaded (not necessarily parallel) execution.
> 
> I have. I don't see it as practical or even really desirable in the
> foreseeable future.

I think you have misinterpreted what Tom was talking about -- at any
rate, I must beg to differ here.  If your Mercury program makes use of
coroutining, i.e. multithreading at the Mercury level, then you still
need to be able to debug it.  For example, the bug may be that the goal
flounders!

So long as the Mercury runtime itself is single-threaded, with the
Mercury runtime itself doing the multiplexing between different Mercury
threads, multithreading does not pose insurmountable difficulties for
debugging.  You will need to add some new trace event ports, of course
(`delay' and `resume', for example, and perhaps also `fork' and `join'
or something like that).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.