Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: "White House to Developers: Using C or C++ Invites Cybersecurity
 Risks"
Date: Mon, 29 Apr 2024 13:42:50 -0700
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <v0p0oa$1uq6q$7@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>
 <v0mo7t$1arr4$3@dont-email.me> <v0nq80$1lv6p$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 29 Apr 2024 22:42:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="68a1f8b2290ba520f984bb7e7fb4eebe";
	logging-data="2058458"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18qDSZMO0v/KKf5tW7OTsKI40Kb6PhVd7Q="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:89voNU80gR9UDTSV3rcLszo2BgE=
In-Reply-To: <v0nq80$1lv6p$1@dont-email.me>
Content-Language: en-US
Bytes: 3499

On 4/29/2024 2:45 AM, paavo512 wrote:
> On 29.04.2024 03:05, Lawrence D'Oliveiro wrote:
>> On Fri, 8 Mar 2024 14:41:16 +0200, Paavo Helde wrote:
>>
>>> AFAIK CPython uses reference counting ...
>>
>> Combination of reference-counting as a first resort, with full garbage
>> collection to deal with those less common cases where you have reference
>> cycles. Trying to get the best of both worlds.
>>
>> The trouble with reference-counting is it impacts multithreading
>> performance. 
> 
> Maybe only in case of heavy contention. If there is little contention 
> and the reference counter is implemented as an atomic variable, there is 
> no measurable hit on performance. I know this because I was suspicious 
> myself and measured this recently.

All of the memory barriers and atomic ops in general reference counting 
can become a rather big issue. Now, there are specialized types of 
reference counting... Think of proxy reference counting. This can 
amortize the counting and can give pretty good performance. Not as good 
as RCU, but not that bad!


> 
> Anyway, multithreading performance is a non-issue for Python so far as 
> the Python interpreter runs in a single-threaded regime anyway, under a 
> global GIL lock. They are planning to get rid of GIL, but this work is 
> still in development AFAIK. I'm sure it will take years to stabilize the 
> whole Python zoo without GIL.
> 
> 
> However, the CPython developers have a scheme to deal with
>> this, by making the reference counts a little less deterministic (i.e.
>> there may be a slight delay before they become fully correct). I think
>> this is a complicated idea, and it may take them some time to get it 
>> fully
>> implemented.
>