[m-rev.] for review: Support dynamic creation of Mercury engines in low-level C parallel grades.

Paul Bone paul at bone.id.au
Wed Jun 25 18:56:39 AEST 2014


On Wed, Jun 25, 2014 at 06:07:14PM +1000, Peter Wang wrote:
> On Wed, 25 Jun 2014 14:29:42 +1000, Paul Bone <paul at bone.id.au> wrote:
> > > > > diff --git a/runtime/mercury_wrapper.h b/runtime/mercury_wrapper.h
> > > > > index 4f7ce48..3a4a50c 100644
> > > > > --- a/runtime/mercury_wrapper.h
> > > > > +++ b/runtime/mercury_wrapper.h
> > > > > @@ -258,7 +258,7 @@ extern MR_Unsigned          MR_contexts_per_thread;
> > > > >  
> > > > >  /*
> > > > >  ** The number of outstanding contexts we can create
> > > > > -** (MR_contexts_per_thread * MR_num_threads).
> > > > > +** (MR_contexts_per_thread * MR_num_ws_engines).
> > > > >  */
> > > > >  extern MR_Unsigned          MR_max_outstanding_contexts;
> > > > >  
> > > > 
> > > > That raises a question.  Are contexts created for thread.spawn_native
> > > > counted towards this limit?
> > > 
> > > Yes, because it is a (crude) attempt to limit memory usage.
> > 
> > Okay, that's fair enough.  It should be in a comment somewhere, probably
> > here though.
> 
> Oh, I see.  Exclusive contexts would eat into the number of contexts
> that work-stealing engines can use, which is probably unexpected.
> Rather, exclusive contexts should NOT count towards
> MR_max_outstanding_contexts (and MR_max_outstanding_contexts and
> MR_max_contexts_per_thread should be renamed).

I'm not too worried but I do think that this behavour is better, it's
probably the "most expected" behavour.


-- 
Paul Bone



More information about the reviews mailing list