Hi Takashi,

On Mar 26 18:14, Takashi Yano wrote:
> Hi Corinna,
> 
> On Mon, 24 Mar 2025 16:35:08 +0100
> Corinna Vinschen wrote:
> > On Mar 24 22:05, Takashi Yano wrote:
> > > Hi Corinna,
> > > 
> > > On Mon, 24 Mar 2025 11:57:06 +0100
> > > Corinna Vinschen wrote:
> > > > I wonder if we shouldn't drop the keys list structure entirely, and
> > > > convert "keys" to a simple sequence number + destructor array, as in
> > > > GLibc.  This allows lockless key operations and drop the entire list and
> > > > mutex overhead.  The code would become dirt-easy, see
> > > > https://sourceware.org/cgit/glibc/tree/nptl/pthread_key_create.c
> > > > https://sourceware.org/cgit/glibc/tree/nptl/pthread_key_delete.c
> > > > 
> > > > What do you think?
> > > 
> > > It looks very simple and reasonable to me.
> > > 
> > > > However, for 3.6.1, the below patch should be ok.
> > > 
> > > What about reimplementing pthread_key_create/pthread_key_delete
> > > based on glibc for master branch, and appling this patch to
> > > cygwin-3_6-branch?
> > > 
> > > Shall I try to reimplement them?
> > 
> > That would be great!
> 
> What about the patch attached?
> Is this as you intended?

Yes!

>  private:
> -  static List<pthread_key> keys;
> +  int key_idx;
> +  static class keys_list {
> +    ULONG seq;

GLibc uses uintptr_t for the sequence number to avoid overflow.
So we could use ULONG64 and InterlockedCompareExchange64 here, too.

Looks good to me, thanks!


Corinna

Reply via email to