> > (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.
That's what I was thinking when I said "option 3". It shouldn't be *too*
hard, and much cleaner.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
