home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 263,913 of 264,096   
   =?UTF-8?Q?Arne_Vajh=C3=B8j?= to Dan Cross   
   Re: more CMA   
   05 Dec 25 18:39:45   
   
   From: arne@vajhoej.dk   
      
   On 12/5/2025 12:15 PM, Dan Cross wrote:   
   > In article <69320352$0$673$14726298@news.sunsite.dk>,   
   > Arne Vajhøj   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca