From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | RE: Hardwired MAXBACKENDS limit could be history |
Date: | 2001-01-26 18:24:12 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D32C2@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Felix König | 2001-01-26 18:27:24 | Trouble porting postgreSQL to WinNT |
Previous Message | Mikheev, Vadim | 2001-01-26 18:02:59 | RE: Open 7.1 items |