From Newsgroup: comp.os.vms

I got some things working, but now I am stuck with:

%SYSTEM-F-INSFMEM, insufficient dynamic memory

What to do?

Bump NPAGEDYN?

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gqr6c$3saak$1@dont-email.me>,
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:

I got some things working, but now I am stuck with:

%SYSTEM-F-INSFMEM, insufficient dynamic memory

What to do?

Contact your authorized D|I|G|I|T|A|L representative to purchase more
memory cards. Do not, under any circumstances, call Clearpoint or
Dataram or any other unauthorized and probably communist vendors of
memory products.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/4/25 02:21, Arne Vajh|+j wrote:

I got some things working, but now I am stuck with:

%SYSTEM-F-INSFMEM, insufficient dynamic memory

What to do?

Bump NPAGEDYN?

More likely to be PAGEDYN rather than NPAGEDYN.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-12-03, Scott Dorsey <kludge@panix.com> wrote:

In article <10gqr6c$3saak$1@dont-email.me>,
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:

I got some things working, but now I am stuck with:

%SYSTEM-F-INSFMEM, insufficient dynamic memory

What to do?

Contact your authorized D|I|G|I|T|A|L representative to purchase more
memory cards. Do not, under any circumstances, call Clearpoint or
Dataram or any other unauthorized and probably communist vendors of
memory products.

...and under no circumstances are you to contact your DEC field service
account manager and discover they may offer better pricing for support
on third party memory than the DEC product.

That comment is not a joke BTW (but I don't know if it applied to memory).
Back when terminal servers were still a thing, I needed to decide between recommending the DEC product range or the cheaper Emulex P4000 product
range for a batch of terminal servers.

The decision was made for me when I discovered that DEC Field Service
would support the Emulex terminal servers and that their support price
was cheaper than the support price for the equivalent DEC products at
the time. :-)

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/4/2025 7:04 AM, Roy Omond wrote:

On 12/4/25 02:21, Arne Vajh|+j wrote:

I got some things working, but now I am stuck with:

%SYSTEM-F-INSFMEM, insufficient dynamic memory

What to do?

Bump NPAGEDYN?

More likely to be PAGEDYN rather than NPAGEDYN.

I have tried bumbing both.

No luck.

A sequence of:

cma_thread_create
cma_mutex_lock
cma_mutex_unlock
cma_thread_join

and after a little over 10000 iterations:

%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
%TRACE-I-NOMSG, Message number 00098043

No idea what 00098054 and 00098043 means - can't find
those message definitions anywhere.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Am 04.12.2025 um 15:23 schrieb Arne Vajh|+j:

A sequence of:

cma_thread_create
cma_mutex_lock
cma_mutex_unlock
cma_thread_join

and after a little over 10000 iterations:

%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
%TRACE-I-NOMSG, Message number 00098043

No idea what 00098054 and 00098043 means - can't find
those message definitions anywhere.

Arne,

AXPVMS $ msgtxt %x00098043
%TRACE-I-END, end of TRACE stack dump

AXPVMS $ msgtxt %x00098054
%TRACE-F-TRACEBACK, symbolic stack dump follows

Try bumping PGFLQUOTA, if it's a process memory problem.

Monitor the running process with $ SHOW PROC/QUOTA/ID=xxx and look for

...
Paging file quota: 494208 Subprocess quota: 10
...

Volker.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/4/2025 10:48 AM, Volker Halle wrote:

Am 04.12.2025 um 15:23 schrieb Arne Vajh|+j:

A sequence of:

cma_thread_create
cma_mutex_lock
cma_mutex_unlock
cma_thread_join

and after a little over 10000 iterations:

%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
%TRACE-I-NOMSG, Message number 00098043

No idea what 00098054 and 00098043 means - can't find
those message definitions anywhere.

AXPVMS $ msgtxt %x00098043
%TRACE-I-END, end of TRACE stack dump

AXPVMS $ msgtxt %x00098054
%TRACE-F-TRACEBACK, symbolic stack dump follows

Try bumping PGFLQUOTA, if it's a process memory problem.

Monitor the running process with $ SHOW PROC/QUOTA/ID=xxx and look for

...
-aPaging file quota:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 494208-a Subprocess quota:-a-a-a-a-a-a-a 10
...

I am running with a pretty big PGFLQUOTA. 4 million.

I have about 3 million left when I hit INSFMEM.

Arne



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-12-04, Arne Vajhoj <arne@vajhoej.dk> wrote:

A sequence of:

cma_thread_create
cma_mutex_lock
cma_mutex_unlock
cma_thread_join

and after a little over 10000 iterations:

%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
%TRACE-I-NOMSG, Message number 00098043

Resource leak ?

Try adding a sleep for 5 seconds after every 500 iterations and use
commands such as show proc/acc to see if memory usage is growing or
if quotas are being depleted.

Given that it is terminating with an error, forcing a process dump
is also a possibility.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/4/2025 1:29 PM, Simon Clubley wrote:

On 2025-12-04, Arne Vajh|+j <arne@vajhoej.dk> wrote:

A sequence of:

cma_thread_create
cma_mutex_lock
cma_mutex_unlock
cma_thread_join

and after a little over 10000 iterations:

%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
%TRACE-I-NOMSG, Message number 00098043

Resource leak ?

Definitely.

But the code is rather simple.

Shortest reproducer:

#include <stdio.h>
#include <stdlib.h>

#include <unistd.h>
#include <cma.h>

void *run(void *p)
{
if(p != NULL) printf("arg pointer = %p\n", p);
return NULL;
}

int main()
{
cma_t_thread t;
cma_t_exit_status stat;
void *p;
cma_init();
int n = 0;
while(1)
{
cma_thread_create(&t, &cma_c_null, run, NULL);
cma_thread_join(&t, &stat, &p);
if(p != NULL) printf("return pointer = %p\n", p);
n++;
printf("%d\n", n);
}
return 0;
}

That code is not doing much.

With this code I get the problem after 16431 good iteration
and a stack trace.

16429
16430
16431
%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
image module routine line rel PC abs PC PTHREAD$RTL 0 000000008001DA53 FFFF8300088DDA53
CMA$OPEN_RTL 0 0000000080003848 FFFF830008F52848
CMA$OPEN_RTL 0 00000000800000FC FFFF830008F4F0FC
z Z main 12400 000000000000008F 000000008000008F
z Z __main 12391 0000000000000113 0000000080000113
PTHREAD$RTL 0 000000008003F28C FFFF8300088FF28C
PTHREAD$RTL 0 0000000080000331 FFFF8300088C0331
0 FFFF8300071C81C6 FFFF8300071C81C6
DCL 0 000000008006632B 000000007ADC432B
%TRACE-I-NOMSG, Message number 00098043

Line 12400 is:

2 12400 cma_thread_create(&t, &cma_c_null, run, NULL);

So cma_thread_create allocate some resources and
cma_thread_join does not free them all and eventually
this runs out of resources.

That was on x86-64. On my Alpha is goes to 18808:

18806
18807
18808
%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
PTHREAD$RTL 0 000000000004310C FFFFFFFF80A3B10C
CMA$OPEN_RTL 0 00000000000301D4 FFFFFFFF80C8C1D4
z 0 0000000000020184 0000000000020184
z 0 00000000000200DC 00000000000200DC
PTHREAD$RTL 0 0000000000056728 FFFFFFFF80A4E728
PTHREAD$RTL 0 0000000000030444 FFFFFFFF80A28444
0 FFFFFFFF80340964 FFFFFFFF80340964
%TRACE-I-END, end of TRACE stack dump


Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-12-04, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 12/4/2025 1:29 PM, Simon Clubley wrote:

On 2025-12-04, Arne Vajhoj <arne@vajhoej.dk> wrote:

A sequence of:

cma_thread_create
cma_mutex_lock
cma_mutex_unlock
cma_thread_join

and after a little over 10000 iterations:

%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
%TRACE-I-NOMSG, Message number 00098043

Resource leak ?

Definitely.

But the code is rather simple.

Shortest reproducer:

#include <stdio.h>
#include <stdlib.h>

#include <unistd.h>
#include <cma.h>

void *run(void *p)
{
if(p != NULL) printf("arg pointer = %p\n", p);
return NULL;
}

int main()
{
cma_t_thread t;
cma_t_exit_status stat;
void *p;
cma_init();
int n = 0;
while(1)
{
cma_thread_create(&t, &cma_c_null, run, NULL);
cma_thread_join(&t, &stat, &p);
if(p != NULL) printf("return pointer = %p\n", p);
n++;
printf("%d\n", n);
}
return 0;
}

That code is not doing much.

With this code I get the problem after 16431 good iteration
and a stack trace.

[snip]

1) What is the reason for using the CMA interface instead of the pthread interface ? If there is no specific reason, perhaps rewriting it as a
pthreads application might give some clues.

2) I assume cma_thread_create() and cma_thread_join() both return status
codes ? (pthread does). Try capturing them and displaying them.

3) Have you tried my suggestion to put 5 second pauses in the code so
you have a chance to try and find out which resource is being consumed ?

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/4/2025 2:49 PM, Simon Clubley wrote:

1) What is the reason for using the CMA interface instead of the pthread interface ? If there is no specific reason, perhaps rewriting it as a pthreads application might give some clues.

I already have working pthreads code.

I wanted to do the same with cma.

Same reason that people climb MtEverest.

2) I assume cma_thread_create() and cma_thread_join() both return status codes ? (pthread does). Try capturing them and displaying them.

No.

void
cma_thread_create (
cma_t_thread *new_thread,
cma_t_attr *attr,
cma_t_start_routine start_routine,
cma_t_address arg);

void
cma_thread_join (
cma_t_thread *thread,
cma_t_exit_status *exit_status,
cma_t_address *result);

3) Have you tried my suggestion to put 5 second pauses in the code so
you have a chance to try and find out which resource is being consumed ?

Yes (not timed pause but press return to continue).

Neither SHOW PROC/QUO or SHOW PROC/ACC show anything critical.

Page file quota remaining goes down, so it is leaking memory.

But there are 2 million left when it crashes.

I wonder if I am running out of thread stack space.

Anyway no matter what is causing the crash - it should not leak.

When the thread is terminated and joined, then anything allocated
at create should be released.

Arne



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/4/2025 2:12 PM, Arne Vajh|+j wrote:

On 12/4/2025 1:29 PM, Simon Clubley wrote:

On 2025-12-04, Arne Vajh|+j <arne@vajhoej.dk> wrote:

A sequence of:

cma_thread_create
cma_mutex_lock
cma_mutex_unlock
cma_thread_join

and after a little over 10000 iterations:

%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
%TRACE-I-NOMSG, Message number 00098043

Resource leak ?

Definitely.

But the code is rather simple.

Shortest reproducer:

#include <stdio.h>
#include <stdlib.h>

#include <unistd.h>
#include <cma.h>

void *run(void *p)
{
-a-a-a if(p != NULL) printf("arg pointer = %p\n", p);
-a-a-a return NULL;
}

int main()
{
-a-a-a cma_t_thread t;
-a-a-a cma_t_exit_status stat;
-a-a-a void *p;
-a-a-a cma_init();
-a-a-a int n = 0;
-a-a-a while(1)
-a-a-a {
-a-a-a-a-a-a-a cma_thread_create(&t, &cma_c_null, run, NULL);
-a-a-a-a-a-a-a cma_thread_join(&t, &stat, &p);

Insert:

cma_thread_detach(&t);

and memory gets freed.

I don't know if this is intentional.

Usually join is sufficient.

-a-a-a-a-a-a-a if(p != NULL) printf("return pointer = %p\n", p);
-a-a-a-a-a-a-a n++;
-a-a-a-a-a-a-a printf("%d\n", n);
-a-a-a }
-a-a-a return 0;
}

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <69320352$0$673$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/4/2025 2:12 PM, Arne Vajh|+j wrote:

On 12/4/2025 1:29 PM, Simon Clubley wrote:

On 2025-12-04, Arne Vajh|+j <arne@vajhoej.dk> wrote:

A sequence of:

cma_thread_create
cma_mutex_lock
cma_mutex_unlock
cma_thread_join

and after a little over 10000 iterations:

%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
%TRACE-I-NOMSG, Message number 00098043

Resource leak ?

Definitely.

But the code is rather simple.

Shortest reproducer:

#include <stdio.h>
#include <stdlib.h>

#include <unistd.h>
#include <cma.h>

void *run(void *p)
{
-a-a-a if(p != NULL) printf("arg pointer = %p\n", p);
-a-a-a return NULL;
}

int main()
{
-a-a-a cma_t_thread t;
-a-a-a cma_t_exit_status stat;
-a-a-a void *p;
-a-a-a cma_init();
-a-a-a int n = 0;
-a-a-a while(1)
-a-a-a {
-a-a-a-a-a-a-a cma_thread_create(&t, &cma_c_null, run, NULL);
-a-a-a-a-a-a-a cma_thread_join(&t, &stat, &p);

Insert:

cma_thread_detach(&t);

and memory gets freed.

I don't know if this is intentional.

It appears so. From the extant documentation I could find about
CMA threads, in the description of, `cma_thread_create`:

|The thread object exists until the cma_thread_detach routine is
|called **and** the thread terminates, whichever occurs last.

[Emphasis added; note the "and" there.]

Source: https://alpha-supernova.dev.filibeto.org/lib/rel/4.0B/HTML/AA-Q2DPC-TKT1_html/thrd0321.html#cma_thread_create_46

Usually join is sufficient.

With pthreads, yes. Evidently not with CMA.

Why bother with CMA, anyway? Just use pthreads?

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-12-05, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <69320352$0$673$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

Usually join is sufficient.

With pthreads, yes. Evidently not with CMA.

Why bother with CMA, anyway? Just use pthreads?

In his reply to me when I asked the same question, Arne said he had
a working phtreads version, but he wanted to try CMA as well because
it was there.

I must admit I've been guilty of the same thing at times. :-)

Simon.

PS: Sometimes I even learnt something new I was not expecting...
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/4/25 15:23, Arne Vajh|+j wrote:

%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
%TRACE-I-NOMSG, Message number 00098043

No idea what 00098054 and 00098043 means - can't find
those message definitions anywhere.

$ set message sys$message:DBGTBKMSG

You probably did not get the message text, because this message file
could not be (merge) activated: because of the resource problem.

You very likely would not have gotten a process dump, because IMGDMP,
which contains the code to write it, could not not be (merge) activated
or could not write a process dump: because of the resource problem.

These are known limitations of TRACE and IMGDMP. You may be able to work around the activation problems with adding the according shareable
images to your main image. Obviously, this will not change anything if
your program lacks a resource that TRACE or IMGDMP need to print the
call trace or to write the process dump.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/5/2025 3:52 PM, hb0815 wrote:

On 12/4/25 15:23, Arne Vajh|+j wrote:

%SYSTEM-F-INSFMEM, insufficient dynamic memory
%TRACE-F-NOMSG, Message number 00098054
%TRACE-I-NOMSG, Message number 00098043

No idea what 00098054 and 00098043 means - can't find
those message definitions anywhere.

$ set message sys$message:DBGTBKMSG

You probably did not get the message text, because this message file
could not be (merge) activated: because of the resource problem.

They did not tell much anyway:

$ set message sys$message:DBGTBKMSG
$ write sys$output f$message(%x00098054)
%TRACE-F-TRACEBACK, symbolic stack dump follows
$ write sys$output f$message(%x00098043)
%TRACE-I-END, end of TRACE stack dump

But problem solved so happy until next problem.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/5/2025 12:15 PM, Dan Cross wrote:

In article <69320352$0$673$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

Insert:

cma_thread_detach(&t);

and memory gets freed.

I don't know if this is intentional.

It appears so. From the extant documentation I could find about
CMA threads, in the description of, `cma_thread_create`:

|The thread object exists until the cma_thread_detach routine is
|called **and** the thread terminates, whichever occurs last.

[Emphasis added; note the "and" there.]

So it is documented, which obviously make it intentional.

Usually join is sufficient.

First a correction of myself.

join is sufficient for GC languages.

For non-GC languages join + destructor is sufficient.

But nobody is surprised that their C++ code is leaking
memory if they forget:
delete t;

With pthreads, yes. Evidently not with CMA.

It is a weird usage if we look at what a thread_detach
function does.

function thread_detach() {
// test inserted in V1.1 to handle cases where the thread completed before this function got called
if(thread is terminated) {
call thread_free()
return
}
// change state
state = detached // any attempts to join will now fail
// setup free at termination
on_termination_handler = function {
call thread_free()
}
}

Calling this function after a join that ensures thread
is terminated will obviously free.

But why not expose the thread_free function?

Or let thread_join call thread_free, because thread_join
knows that the thread is terminated before it completes.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/4/2025 3:59 PM, Arne Vajh|+j wrote:

On 12/4/2025 2:49 PM, Simon Clubley wrote:

1) What is the reason for using the CMA interface instead of the pthread
interface ? If there is no specific reason, perhaps rewriting it as a
pthreads application might give some clues.

I already have working pthreads code.

I wanted to do the same with cma.

There are something in cma not present in pthread.

The cma API comes with the cma_lib_queue_* functions.

Doing similar to java.util.concurrent.BlockingQueue
if you are familiar with that.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gv701$1klbu$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-12-05, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <69320352$0$673$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

Usually join is sufficient.

With pthreads, yes. Evidently not with CMA.

Why bother with CMA, anyway? Just use pthreads?

In his reply to me when I asked the same question, Arne said he had
a working phtreads version, but he wanted to try CMA as well because
it was there.

I must admit I've been guilty of the same thing at times. :-)

Ah. Well, I guess there's nothing wrong with that.

PS: Sometimes I even learnt something new I was not expecting...

I think that one of the challenging things about working with
deprecated interfaces like this, particularly those that aren't
very well documented anymore, is that one's intuition from their
replacements may not be accurate. I believe that's the case
here; behavior one reasonably expects from working with pthreads
is not consistent with the actual behavior of CMA.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gvqg1$1stts$2@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/5/2025 12:15 PM, Dan Cross wrote:

In article <69320352$0$673$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

Insert:

cma_thread_detach(&t);

and memory gets freed.

I don't know if this is intentional.

It appears so. From the extant documentation I could find about
CMA threads, in the description of, `cma_thread_create`:

|The thread object exists until the cma_thread_detach routine is
|called **and** the thread terminates, whichever occurs last.

[Emphasis added; note the "and" there.]

So it is documented, which obviously make it intentional.

That's my read of it.

Usually join is sufficient.

First a correction of myself.

join is sufficient for GC languages.

For non-GC languages join + destructor is sufficient.

Well, it depends on your definition of "sufficient."

I took you to mean, "to reclaim the resources used by the thread
library." Obviously other program-managed data falls outside of
the realm of what should be done by the library when joining a
thread; if one allocated a heap object and did not free it when
the thread terminated and was joined, that would be a leak in a
language without automatic memory management.

But nobody is surprised that their C++ code is leaking
memory if they forget:
delete t;

Of course. That seems orthogonal to what the thread library
would do, however. Given your minimal example, where the
program did no direct allocation of memory, it seemed logical
that the error must be in how the interface was used.

With pthreads, yes. Evidently not with CMA.

It is a weird usage if we look at what a thread_detach
function does.

function thread_detach() {
// test inserted in V1.1 to handle cases where the thread completed
before this function got called
if(thread is terminated) {
call thread_free()
return
}
// change state
state = detached // any attempts to join will now fail
// setup free at termination
on_termination_handler = function {
call thread_free()
}
}

Calling this function after a join that ensures thread
is terminated will obviously free.

But why not expose the thread_free function?

Presumably because someone might call it on a still-running
thread by accident. It's unclear what the semantics _should_
be.

But I'm speculating.

Or let thread_join call thread_free, because thread_join
knows that the thread is terminated before it completes.

It seems that the POSIX committee that created pthreads asked
the same questions and decided there was no good reason for
thread join _not_ to free the resources in question.

If I were to hazard a guess, CMA requires both steps in order to
work around a race condition of some kind. I see in the CMA
documentation that multiple threads may join on a given thread;
all are unblocked when the thread terminates. This is, again,
unlike pthreads, where only one thread my join on a thread. The
two-step mechanism for freeing might have been mean to give CMA
threads a way to coordinate multiple joiners, where the last one
to reference the thread detachs it, thus freeing the resources.

But again, I'm speculating.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <69345887$0$663$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/4/2025 3:59 PM, Arne Vajh|+j wrote:

On 12/4/2025 2:49 PM, Simon Clubley wrote:

1) What is the reason for using the CMA interface instead of the pthread >>> interface ? If there is no specific reason, perhaps rewriting it as a
pthreads application might give some clues.

I already have working pthreads code.

I wanted to do the same with cma.

There are something in cma not present in pthread.

The cma API comes with the cma_lib_queue_* functions.

Presumably this doesn't exist in pthreads because it's simple to
do oneself using the tools that interface gives you (mutexes and
condition variables, specifically).

For example, I whipped this up earlier today as a demonstration: https://github.com/dancrossnyc/cqueue/blob/main/cqueue.c

(The `try_*` implementations left as an exercise for the reader;
they are very simple, but I just could't be bothered.)

Nothing in the CMA lib APIs strikes me as particularly worth
adding it to the interface, and one can imagine all sorts of
enhancements that it just doesn't provide (prioritization;
fairness; sending by value instead of reference, etc).

For non-trivial applications, I imagine the pthreads folks
decided that it was probably better to do it yourself, or find
a third-party library better suited to the specific use case.

Doing similar to java.util.concurrent.BlockingQueue
if you are familiar with that.

Well, not quite. That's generic over some element type, E. The
CMA library functions, and my own trivial example, just use a
pointer, which is rather different.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/8/2025 3:55 PM, Dan Cross wrote:

In article <69345887$0$663$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

There are something in cma not present in pthread.

The cma API comes with the cma_lib_queue_* functions.

Presumably this doesn't exist in pthreads because it's simple to
do oneself using the tools that interface gives you (mutexes and
condition variables, specifically).

It is almost always possible to go DIY.

But why? If someone else is willing to do it, then it is great!

Nothing in the CMA lib APIs strikes me as particularly worth
adding it to the interface, and one can imagine all sorts of
enhancements that it just doesn't provide (prioritization;
fairness; sending by value instead of reference, etc).

Don't let perfect be the enemy of good.

Doing similar to java.util.concurrent.BlockingQueue
if you are familiar with that.

Well, not quite. That's generic over some element type, E. The
CMA library functions, and my own trivial example, just use a
pointer, which is rather different.

The Java version is more type safe than the C version.

But I think that matches the preference of both Java and C
people.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10h807g$hm6v$2@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/8/2025 3:55 PM, Dan Cross wrote:

In article <69345887$0$663$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

There are something in cma not present in pthread.

The cma API comes with the cma_lib_queue_* functions.

Presumably this doesn't exist in pthreads because it's simple to
do oneself using the tools that interface gives you (mutexes and
condition variables, specifically).

It is almost always possible to go DIY.

But why? If someone else is willing to do it, then it is great!

Because by doing so, one conflates mechanism and policy, and one
runs the risk of choosing the existing policy implementation in
places where it's really not appropriate, simply because that's
what's already there.

Nothing in the CMA lib APIs strikes me as particularly worth
adding it to the interface, and one can imagine all sorts of
enhancements that it just doesn't provide (prioritization;
fairness; sending by value instead of reference, etc).

Don't let perfect be the enemy of good.

Sure. But the hard part of software engineering is finding the
right balance between adopting canned solutions to common
problems juxtaposted with forcing a particular design "shape"
onto programs.

Threads are a basic building block for concurrent programs; they
are mechanism, and as such, it makes sense to provide some
primitive exposing them, particularly on systems where a thread
is an OS-managed object. On the other hand, the specific
implementation of queues is a lot closer to policy, for the
aforementioned reasons (a queue for a particular application may
want to take into account priority of queued items, or fairness
and hysteresis with respect to scheduling produces and
consumers, etc). Thus, it makes less sense to provide them as a
library abstraction.

Doing similar to java.util.concurrent.BlockingQueue
if you are familiar with that.

Well, not quite. That's generic over some element type, E. The
CMA library functions, and my own trivial example, just use a
pointer, which is rather different.

The Java version is more type safe than the C version.

But I think that matches the preference of both Java and C
people.

Generics gove a measure od type safety not managable in C.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2