Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.vms > #378300 > unrolled thread

more CMA

Back to article view | Back to comp.os.vms

Contents

  more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-03 21:21 -0500
    Re: more CMA kludge@panix.com (Scott Dorsey) - 2025-12-03 21:38 -0500
      Re: more CMA Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-04 13:40 +0000
    Re: more CMA Roy Omond <roy@omond.net> - 2025-12-04 12:04 +0000
      Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 09:23 -0500
        Re: more CMA Volker Halle <volker_halle@hotmail.com> - 2025-12-04 16:48 +0100
          Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 11:55 -0500
        Re: more CMA Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-04 18:29 +0000
          Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 14:12 -0500
            Re: more CMA Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-04 19:49 +0000
              Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 15:59 -0500
                Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-06 11:23 -0500
                  Re: more CMA cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-08 20:55 +0000
                    Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-08 21:06 -0500
                      Re: more CMA cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-09 04:46 +0000
            Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 16:55 -0500
              Re: more CMA cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-05 17:15 +0000
                Re: more CMA Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-05 18:06 +0000
                  Re: more CMA cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-08 12:33 +0000
                Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-05 18:39 -0500
                  Re: more CMA cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-08 14:14 +0000
        Re: more CMA hb0815 <mw40171@mucweb.de> - 2025-12-05 21:52 +0100
          Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-05 18:21 -0500

Page 1 of 2  [1] 2  Next page →

#378300 — more CMA

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

%SYSTEM-F-INSFMEM, insufficient dynamic memory

What to do?

Bump NPAGEDYN?

Arne

[toc] | [next] | [standalone]

#378301

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."

[toc] | [prev] | [next] | [standalone]

#378303

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.

[toc] | [prev] | [next] | [standalone]

#378302

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.

[toc] | [prev] | [next] | [standalone]

#378307

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

[toc] | [prev] | [next] | [standalone]

#378309

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.

[toc] | [prev] | [next] | [standalone]

#378310

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
> 
> ...
>   Paging file quota:                494208  Subprocess quota:        10
> ...

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

I have about 3 million left when I hit INSFMEM.

Arne

[toc] | [prev] | [next] | [standalone]

#378311

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 ?

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.

[toc] | [prev] | [next] | [standalone]

#378312

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

[toc] | [prev] | [next] | [standalone]

#378313

On 2025-12-04, Arne Vajhøj <arne@vajhoej.dk> 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)
> {
>      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.

[toc] | [prev] | [next] | [standalone]

#378314

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

[toc] | [prev] | [next] | [standalone]

#378329

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

[toc] | [prev] | [next] | [standalone]

#378350

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.

[toc] | [prev] | [next] | [standalone]

#378354

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

[toc] | [prev] | [next] | [standalone]

#378356

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.

[toc] | [prev] | [next] | [standalone]

#378316

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)
> {
>      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);

Insert:

cma_thread_detach(&t);

and memory gets freed.

I don't know if this is intentional.

Usually join is sufficient.

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

Arne

[toc] | [prev] | [next] | [standalone]

#378318

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)
>> {
>>      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);
>
>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.

[toc] | [prev] | [next] | [standalone]

#378319

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.

[toc] | [prev] | [next] | [standalone]

#378343

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.

[toc] | [prev] | [next] | [standalone]

#378322

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.vms

csiph-web