Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: "White House to Developers: Using C or C++ Invites Cybersecurity
 Risks"
Date: Fri, 8 Mar 2024 17:55:48 +0100
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <usffuk$1q99e$1@dont-email.me>
References: <us0brl$246bf$1@dont-email.me> <us1lb5$2f4n4$1@dont-email.me>
 <us2lfh$2ltj3$5@dont-email.me> <us2s96$2n6h3$6@dont-email.me>
 <us3155$2of1i$3@dont-email.me> <us4c66$346tp$3@dont-email.me>
 <us5d6f$3besu$3@dont-email.me> <20240305005948.00002697@yahoo.com>
 <us5u16$3eidj$2@dont-email.me> <20240305111103.00003081@yahoo.com>
 <us8821$90p$4@dont-email.me> <20240306140214.0000449c@yahoo.com>
 <us9nib$dski$1@dont-email.me> <20240307000008.00003544@yahoo.com>
 <usc58s$10cls$1@dont-email.me> <20240307134401.00007aa2@yahoo.com>
 <uscmub$149j3$1@dont-email.me> <usf11f$1mk5l$1@dont-email.me>
 <usf63j$1nnsb$1@dont-email.me> <usfa2o$1orr3$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 8 Mar 2024 16:55:48 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="5b4fd483861029d4eca5978ecaa265e3";
	logging-data="1910062"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5xEKDmLw27DVhWH6hUbatF3Mv1JEwcwM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:Db8WrX/RpvKx1yCTEcoRJUx1wZo=
In-Reply-To: <usfa2o$1orr3$1@dont-email.me>
Content-Language: en-GB
Bytes: 3672

On 08/03/2024 16:15, bart wrote:
> On 08/03/2024 14:07, David Brown wrote:
>> On 08/03/2024 13:41, Paavo Helde wrote:
>>> 07.03.2024 17:36 David Brown kirjutas:
>>>>
>>>> CPython does use garbage collection, as far as I know.
>>>>
>>>
>>> AFAIK CPython uses reference counting, i.e. basically the same as C++ 
>>> std::shared_ptr (except that it does not need to be thread-safe).
>>
>> Yes, that is my understanding too.  (I could be wrong here, so don't 
>> rely on anything I write!)  But the way it is used is still a type of 
>> garbage collection.  When an object no longer has any "live" 
>> references, it is put in a list, and on the next GC it will get 
>> cleared up (and call the asynchronous destructor, __del__, for the 
>> object).
> 
> Is that how CPython works? I can't quite see the point of saving up all 
> the deallocations so that they are all done as a batch. It's extra 
> overhead, and will cause those latency spikes that was the problem here.

I believe the GC runs are done very regularly (if there is something in 
the clean-up list), so there is not much build-up and not much extra 
latency.

> 
> In my own reference count scheme, when the count reaches zero, the 
> memory is freed immediately.

That's synchronous deallocation.  It's a perfectly good strategy, of 
course.  There are pros and cons of both methods.

> 
> I also tend to have most allocations being of either 16 or 32 bytes, so 
> reuse is easy. It is only individual data items (a long string or long 
> array) that might have an arbitrary length that needs to be in 
> contiguous memory.
> 
> Most strings however have an average length of well below 16 characters 
> in my programs, so use a 16-byte allocation.
> 
> I don't know the allocation pattern in that Discard app, but Michael S 
> suggested they might not be lots of arbitrary-size objects.
>