[m-rev.] for post-commit review: document .par grades

[Zoltan Somogyi]

On Sun, 17 Aug 2025 00:41:47 +1000, Julien Fischer <jfischer at opturion.com> wrote:

> On Sat, 16 Aug 2025 at 23:54, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> >
> > On Sat, 16 Aug 2025 23:29:47 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > Yet you say later that concurrency (using multiple threads, even if on one CPU,
> > will be supported in "Non .par LLDS grades". What is the reason for this support
> > being a separate grade modifier for high level C, but a builtin-in capability
> > in low level C?
> 
> In order to support concurrency, something has to have the capability to execute
> Mercury threads.  In LLDS grades, that something is an engine.  Regardless of
> whether we are in an LLDS .par grade or not, there will be at least one engine
> present, so concurrency is always possible (albeit not in parallel in
> the single engine case).
> In non .par hlc grades there is nothing to execute the threads, since
> C does not provide
> that capability as part of the language. The pthreads library provides
> the capability and
> pthreads is only included in the .par grades.

Ok, that works for me.

> > > Under this scheme, concurrency will be supported in
> > >
> > > 1. The Java and C# grades.
> > > 2. The hlc.mt grades.
> > > 3. Non .par LLDS grades (not in parallel)
> > > 4. .par LLDS grades (in parallel)
> >
> > Agreed about 1, 2 and 4. About 3, we should await the results of your test,
> > and even then, I would need to see something equivalent to a design
> > document that says how it is supposed to work, because without that,
> > it cannot be maintained long term.
> 
> I tried (3) with asm_fast.gc on some of the concurrency examples earlier this
> evening.  They seem to work.  That said, so far as I can recall, every
> discussion
> I've ever had about this capability is that it doesn't work well.  I would happy
> to drop it and just not allow concurrency in non .par LLDS grades.

I would not be affected by a decision either way, so I have no objection.
Does anyone else on this list have an objection? Peter?

> > Note also that agreeing on a scheme would be good,
> 
> Let me pose the first question as part of a proposed scheme: should
> we continue to allow concurrency in non .par LLDS grades?  (Which is
> a no from me.)

You already proposed it a dozen (mostly elided) lines above :-)

Zoltan.