From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: Win32 latch implementation revisited |
Date: | 2010-09-14 14:38:52 |
Message-ID: | 5490.1284475132@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2010-09-14 14:57:14 | Re: pg_ctl emits strange warning message |
Previous Message | Tom Lane | 2010-09-14 14:19:18 | Re: Report: removing the inconsistencies in our CVS->git conversion |