"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> (2) the killer function is PGSemaphoreReset(). There is no direct function
> for this in Win32 either.
If you can do PGSemaphoreTryLock, then Reset need only be a loop around
it (cf. posix_sema.c). In current usage Reset doesn't have to be very
efficient at all, because it's only used during backend startup to bring
the semaphore to a known state.
> (1) semctl(SETVAL, val=0) - there is no other "val" than zero is used;
Really? Better look again.
If you think the SysV interface is baroque (which I don't disagree
with), then you should just get rid of it entirely and implement
pg_sema.h directly atop the Windows primitives. I don't have a lot of
sympathy for "let's implement just part of SysV because I don't like
that other part". There is no contract saying that sysv_sema.c might
not start using SysV features it doesn't use today.
regards, tom lane