> > Did you ever consider remove per-backend semaphores at all?
> > We use them to sleep waiting for lock (ie when someone awake
> > us by changing our semaphore) - why don't use sigpause and
> > some signal?
> 
> That'll fail if the signal arrives before the sigpause(), no?

Ops, you're right.

> > Semaphores are good to sync access to *shared*
> > resources but it's not that case here.
> 
> The thing we really need here is that the right thing has to happen
> if the V() occurs before our P(), ie, the V() has to be remembered
> so that we will fall through the P() without blocking.
> 
> What I'd like to look at sometime soon is using POSIX semaphores
> instead of SysV semaphores.  But we need stateful semaphores,
> not signals.

Conditional variables seem to be more portable - recently I had to
rewrite some program with POSIX sem developed under Solaris when
porting to AIX. (BTW, OmniORB uses cond vars to simulate semaphores).

Vadim

Fri, 26 Jan 2001 10:24:12 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Hardwired MAXBACKENDS limit could be history 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> What I'd like to look at sometime soon is using POSIX semaphores
>> instead of SysV semaphores.  But we need stateful semaphores,
>> not signals.

> Conditional variables seem to be more portable

Really?  Which standard are they specified in?

I have no intention of removing the SysV sem support, mind you;
I just think it might be good to have an alternative implementation
that relies on a more modern standard ...

			regards, tom lane

Fri, 26 Jan 2001 16:33:36 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Hardwired MAXBACKENDS limit could be history 