[m-users.] That parallel low-level C bug

[Volker Wysk]

Am Montag, dem 14.09.2026 um 20:21 +0200 schrieb Zoltan Somogyi:
>
>
> On Mon, 14 Sep 2026 14:36:53 +0200, Volker Wysk <post at volker-wysk.de>
> wrote:
>
> > Am Montag, dem 14.09.2026 um 13:10 +0200 schrieb Zoltan Somogyi:
> > > > Since no "asm_fast.par" grades are available, you need to compile in
> > > > a
> > > > high level C grade instead. But some programs need the tail
> > > > recursion
> > > > optimization, which isn't available there.
> > >
> > > Yes, it is. For about a decade, tail recursion optimization has been
> > > almost as good in high level C grades as in low level C grades.
> > > For most purposes, though not all, they are just as good.
> >
> > Somewhere I've got the notion that there's no TRO in high level C
> > grades...
>
> Twenty years ago, that would have been correct. Then, for several years,
> we supported only self-tail-recursion in high level C grades. Since about
> ten years ago, such grades support both self and mutual tail recursion.
>
> > There indeed is something done after one call of master_loop_abort
>
> Actually, there is probably not. The reason for the lack of tail recursion
> here
> is much simpler. 

But there *is*. You can see it in the generated high-level C code. So there
are two reasons.

> For low level C grades, tail recursive code is smaller
> than the exact same code that is compiled without tail recursion
> optimization.
> For high level C grades, the opposite is true. Therefore the code that
> marks tail recursive calls simply SWITCHES OFF even TRYING to mark
> recursive calls in predicates whose determinism is erroneous.
> This is because such predicates abort the program, 

No, it doesn't. It just throws an exception.

> and whether they take
> a microsecond less or more to do it does not matter, because conditions
> that abort the program should be RARE, and deep recursion within such
> predicates should be EVEN RARER. The compiler therefore prefers
> the space saving from not doing tail recursion optimization to the
> (presumably non-existent in this case) speedup from doing it.
>
> Your example is the first time I have ever seen a recursive predicate
> whose determinism is erroneous. What led you to this design?

It's part of a redesign of the Mfwpar library which I released in april,
which I'm going to release soon. There are multiple threads used by the main
"mfwpar" predicate (master, feeder, workers). When an exception in any of
them is caught, an abortion is initiated. For the master thread, this means
that it waits for the other threads to terminate themselves. Then it
rethrows the exception. This is done by "master_loop_abort". So we don't
have unfinished threads when the exception comes out of the main "mfwpar"
predicate. The other threads announce that they are (almost) terminated by
sending "feeder_terminated" or "worker_terminated" messages to master
through a channel. These messages are received in the "master_loop_abort"
predicate, before it rethrows the exception.

I've attached the complete code of "master_loop_abort".

Cheers,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: master_loop_abort.m
Type: text/x-objcsrc
Size: 2240 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/users/attachments/20260915/81665727/attachment.bin>