Re: Win32 latch implementation revisited - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Win32 latch implementation revisited
Date
Msg-id 5490.1284475132@sss.pgh.pa.us
Whole thread Raw
In response to Win32 latch implementation revisited  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> It just occurred to me that the Windows latch implementation goes 
> through a lot of trouble to dynamically assign the shared Windows event 
> handles to the latches in OwnLatch, but there's really no reason why 
> they can't be statically assigned in InitSharedLatch instead. We have to 
> allocate the same amount of event handles anyway.

> That makes the implementation a lot simpler, eliminating the shared 
> memory block dedicated to latches altogether, and all the related 
> bookkeeping. We no longer need NumSharedLatches() function anymore 
> either, each InitSharedLatch call can allocate a new event handle directly.

That sounds real good.  The only possible downside I can see is this:

> + * InitSharedLatch needs to be called in postmaster before forking child
> + * processes, usually right after allocating the shared memory block
> + * containing the latch with ShmemInitStruct. The Unix implementation
> + * doesn't actually require that, but the Windows one does.

But realistically I think we have to insist on InitSharedLatch being
done during shared memory setup anyway, else there will be race
condition issues.  So no objection here.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Report: removing the inconsistencies in our CVS->git conversion
Next
From: David Fetter
Date:
Subject: Re: pg_ctl emits strange warning message