Initial capability sets patch

[Simon Marlow]

On 03/03/2011 12:02, Duncan Coutts wrote:
> Attached is
>
> Thu Mar  3 11:30:52 GMT 2011  Duncan Coutts<duncan at well-typed.com>
>    * Mark the event number ranges reserved by eden
>    And add a few other explanitory comments.
>
> Thu Mar  3 11:33:04 GMT 2011  Duncan Coutts<duncan at well-typed.com>
>    * Add new capability set concept to the event/trace system
>    Capability sets are a bit of new infrastructure for the ghc
>    event/trace system that hopefully is reasonably generic and will
>    have multiple uses.
>
>    A capability set is just a set of capabilities. Some information
>    that we would like to emit in an event log should be attached not
>    to an individual Haskell thread or RTS capability, but should be
>    identified with a certain set of RTS capabilities. For example the
>    OS process ID is identified with all the capabilities in the RTS
>    instance. The OS PID is not global however: we wish to merge event
>    logs from multiple processes (either concurrent processes or from
>    multiple runs of the same process). A capability set (capset)
>    provides a context to attach such information.
>
>    This patch adds the basic events for keeping track of capability
>    sets. It exposes them both in the event log and via dtrace.
>
>
> At this stage I'm mainly seeking feedback on whether I've got the
> layering right. The GHC event/trace system has an events layer, a
> tracing layer and dtrace layer. The capability set stuff itself is not
> really tracing, it is not something that already happens in the RTS,
> however it's a way of representing a context that will be used by some
> events we plan to add. So we want this info in both the event log and in
> the dtrace layer. I also added it in the debug tracing stuff, but it's
> not obvious that that's needed.
>
> Unlike scheduler events, the capset events are emitted unconditionally.
> This is because they define information/context that will be reused by
> events from multiple trace subsystems (beyond the current single
> category of scheduler events). The simplest thing to do therefore is
> just to emit these events unconditionally. They should be pretty low
> volume, unless users/libs start using them heavily.

It's a little bit fishy, because the types EventCapsetID and EventCapNo 
are exposed via the Trace.h API.  The Event layer is supposed to be 
hidden at this level.  If EventCapsetID and EventCapsetType are concepts 
that need to be visible outside of the Event layer, they should be moved 
and given non-Event names.  I admit it's a little confusing because 
Trace uses Event types and constants internally, but they are only internal.

I thought we were going to keep the Capset stuff in the Event layer and 
not expose it through Trace?  Why does it need to be exposed via Trace?

Cheers,
	Simon




>
> Duncan
>
>
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc