> On 3/16/01, 11:10:34 AM, The Hermit Hacker <[EMAIL PROTECTED]> wrote
> regarding Re: Re[4]: [HACKERS] Allowing WAL fsync to be done via O_SYNC :
>
> > But, with shared libraries, are you really pulling in a "whole
> > thread-support library"? My unders
[ Charset ISO-8859-1 unsupported, converting... ]
> Yes, you are. On UnixWare, you need to add -Kthread, which CHANGES a LOT
> of primitives to go through threads wrappers and scheduling.
This was my concern; the change that happens on startup and lib calls
when thread support comes in through
Tom Lane <[EMAIL PROTECTED]> writes:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> >> definitely need before considering this is to replace the existing
> >> spinlock mechanism with something more efficient.
>
> > What sort of problems are you seeing with the spinlock code?
>
> It's great as
directives.
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 3/16/01, 11:10:34 AM, The Hermit Hacker <[EMAIL PROTECTED]> wrote
regarding Re: Re[4]: [HACKERS] Allowing
Larry Rosenman <[EMAIL PROTECTED]> writes:
>> But, with shared libraries, are you really pulling in a "whole
>> thread-support library"?
> Yes, you are. On UnixWare, you need to add -Kthread, which CHANGES a LOT
> of primitives to go through threads wrappers and scheduling.
Right, it's not so
> We've speculated about using Posix semaphores instead, on platforms
For spinlocks we should use pthread mutex-es.
> where those are available. I think Bruce was concerned about the
And nutex-es are more portable than semaphores.
Vadim
---(end of broadcast)--
On Fri, 16 Mar 2001, Tom Lane wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> >> definitely need before considering this is to replace the existing
> >> spinlock mechanism with something more efficient.
>
> > What sort of problems are you seeing with the spinlock code?
>
> It's great as l
Alfred Perlstein <[EMAIL PROTECTED]> writes:
>> definitely need before considering this is to replace the existing
>> spinlock mechanism with something more efficient.
> What sort of problems are you seeing with the spinlock code?
It's great as long as you never block, but it sucks for making th
* Tom Lane <[EMAIL PROTECTED]> [010316 08:16] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> >> couldn't the syncer process cache opened files? is there any problem I
> >> didn't consider ?
>
> > 1) IPC latency, the amount of time it takes to call fsync will
> >increase by at least t
Alfred Perlstein <[EMAIL PROTECTED]> writes:
>> couldn't the syncer process cache opened files? is there any problem I
>> didn't consider ?
> 1) IPC latency, the amount of time it takes to call fsync will
>increase by at least two context switches.
> 2) a working set (number of files needed
* Xu Yifeng <[EMAIL PROTECTED]> [010316 01:15] wrote:
> Hello Alfred,
>
> Friday, March 16, 2001, 3:21:09 PM, you wrote:
>
> AP> * Xu Yifeng <[EMAIL PROTECTED]> [010315 22:25] wrote:
> >>
> >> Could anyone consider fork a syncer process to sync data to disk ?
> >> build a shared sync queue, when
11 matches
Mail list logo