""Magnus Hagander"" <mha@sollentuna.net> wrote
> >
> > I'm not sure why the win32 port chose to emulate the SysV
> > semaphore interface anyway. You could equally well have used
> > the Posix interface (src/backend/port/posix_sema.c). Or,
> > given Microsoft's NIH tendencies, you might have needed to
> > write a third implementation of the pg_sema.h interface ...
> > but it'd likely still be no larger than win32/sema.c ...
>
> Going with the third option might be a good idea - win32 *does* have
> native semaphores, and most of the work appears to be first adapting our
> need to sysv, then adapting sysv to win32. Worth looking at I guess.
>
Emulating the posix interface has almost the same difficulty as SysV for two
reasons:
(1) we don't have to emulate everything of SysV. For example, the "nops"
parameter of semop() since we don't use it;
(2) the killer function is PGSemaphoreReset(). There is no direct function
for this in Win32 either.
So we might want to fix current win32/sema.c for two problems:
(1) semctl(SETVAL, val=0) - there is no other "val" than zero is used;
(2) concurrent access to sem_counts[];
For problem 1, we can do it by locking the whole session of semaphore
operation (which is the saftest way, but it is performance bad enough), or
we could just do it as the posix_sema.c/PGSemaphoreReset does (which is the
easiest way - just get rid of the EAGAIN report if we can't get it). But
both of them to me, too bad - because I don't really understand why there is
a semctl(SETVAL, val) in SysV anyway - IMHO this does not make any sense -
even if you SETVAL to some value, you are not guranteed that you will stll
get this value just after the function return. The
UnlockBuffers()/UnpinBuffer() fix several days ago have proved this. In
short, if we can get rid of this usage, both POSIX and Win32 will be happy
to see it.
Regards,
Qingqing