It's great as long as you never block, but it sucks for making things
wait, because the wait interval will be some multiple of 10 msec rather
than just the time till the lock comes free.
On the AIX platform usleep (3) is able to really sleep microseconds without
busying the cpu when
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 a daemon process want to do sync after
write() is called, just put a sync
* 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 a daemon process
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 to be
* 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 two context
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 things
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 long as you
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
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 much
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 things
I like optimistic approaches :-)
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 long as you
[ 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
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
It's great as long as you never block, but it sucks for making things
wait, because the wait interval will be some multiple of 10 msec rather
than just the time till the lock comes free.
On the AIX platform usleep (3) is able to really sleep
13 matches
Mail list logo
