[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