Hi,
win32 doesn't support a static initializer for mutexes, thus the first
user must initialize the lock. The problem are concurrent first users
- the pthread_mutex_t initialization must be synchronized.
The current implementation is broken, the attached patches fixes that:
mutex_initlock is a
Hi,
The win32 port doesn't have a native user space spinlock implementation
yet. Attached is an untested patch - could someone test it? I don't have
Visual C++.
--
Manfred
Index: src/include/storage/s_lock.h
===
RCS file:
Andreas Pflug wrote:
I don't really think so. That mutex_initialized is a globally static
variable, not a thread local one. Thread interruption between testing
mutex_initialized and setting it is very unlikely and still wouldn't
do much harm if it actually does happen.
Very unlikely is not a
Andreas Pflug wrote:
Bruce Momjian wrote:
Agreed. My pthread book says pthread_mutex_init() should be called only
once, and we have to guarantee that. If the Windows implentation allows
it to be called multiple times, just create a function to be called only
by Win32 that does that and leave
on failure, which will
be interpreted just the other way round in initialize_SSL.
Patch appended.
Hmm, that looks backwards to me too, but this would seem to imply that
Manfred Spraul failed to test his last patch at all. Manfred, care to
explain why we shouldn't revert that patch in toto
Bruce Momjian wrote:
- patch for thread_test.c needed posted some hours ago.
Applied.
The current CVS tree work again, Andreas' patch fixed the configure failure.
Additionally Andreas' libpq patch fixes ssl. I've tested the locking,
too: ssl calls pq_lockingcallback.
I've tested it by
Bruce Momjian wrote:
I could not get this patch to compile. I am getting a failure because
BSD/OS doesn't have pthread_rwlock_wrlock(). I am concerned other
platforms might not have it either.
I feared that. I'll switch to pthread_mutex_lock()+_unlock().
pthread_rwlock_wrlock()+_unlock was
Bruce Momjian wrote:
+ /*
+* We could lose a signal during this test.
+* In a multi-threaded application, this might
+* be a problem. Do any non-threaded platforms
Threaded or non-threaded?
+* lack sigaction()?
+*/
Additionally, the
Tom Lane wrote:
Is there an easy way find out which LWLock is contended?
Not from oprofile output, as far as I can think. I've suspected for
some time that the BufMgrLock is a major bottleneck, but have no proof.
Mark ran a DBT-2 testrun with the attached statistics patch applied: It
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
Tom Lane wrote:
Don't you have to put it in a specific place in the loop to make that
work? If not, why not?
Rep;nop is just a short delay - that's all.
That view seems to me to be directly contradicted
Tom Lane wrote:
Anyway, I've committed your patch with some changes.
Thanks.
BTW, I noticed a lot of concern in the Intel app notes about reserving
64 or even 128 bytes for each spinlock to avoid cache line conflicts.
That seems excessive to me (we use a lot of spinlocks for buffers), but
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
Intel recommends to add a special pause instruction into spinlock busy
loops. It's necessary for hyperthreading - without it, the cpu can't
figure out that a logical thread does no useful work and incorrectly
awards lots of execution
Shridhar Daithankar wrote:
Does 30% difference above count as significant?
No. It's Linux, we can look at the sources: there is no per-fd cache,
the page cache is global. Thus fsync() syncs the whole cache to disk.
A problem could only occur if the file cache is not global - perhaps a
Neil Conway wrote:
A quick grep of the source tree indicates that the following files
claim to be covered by the 4 clause BSD license:
$ grep -rlI 'This product includes software developed' *
contrib/mysql/my2pg.pl
contrib/pgcrypto/README.pgcrypto
contrib/pgcrypto/blf.c
You must be careful
Hi,
attached is an update of my automatic sigaction patch: I've moved the
actual sigaction calls into pqsignal.c and added a helper function
(pgsignalinquire(signo)). I couldn't remove the include signal.h from
fe-connect.c: it's required for the SIGPIPE definition.
Additionally I've added a
Tom Lane wrote:
Seriously though, if we can move the bulk of the writing work into
background processes then I don't believe that there will be any
significant penalty for regular backends. And I believe that it would
be a huge advantage from a correctness point of view if we could stop
Bruce Momjian wrote:
I thought it should be global too, basically testing on the first
connection request.
What if two PQconnect calls happen at the same time?
I would really prefer the manual approach with a new PQsetsighandler
function - the autodetection is fragile, it's trivial to find a
Tom Lane wrote:
I don't think we need to complicate pqsignal's API for this. Instead
we'd better document that SIGPIPE handling has to be set up and kept
stable before doing any libpq operations in a multithread app.
Not reliable.
An app could install it's own signal handler and block SIGPIPE
Attatched is the latest version of my patch that makes the
signal(SIG_PIPE, SIG_IGN) calls around the send() syscall conditional:
they are not sufficient to ensure that multithreaded libpq users are not
killed by SIGPIPE signals, and they cause a noticable slowdown.
I've switched to a global
pqsecure_write tries to catch SIGPIPE signals generated by network
disconnects by setting the signal handler to SIG_IGN. The current
approach causes several problems:
- it always sets SA_RESTART when it restores the old handler.
- it's not reliable for multi threaded apps, because another thread
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Of course, the linux kernel is aimed at a limited set of compilers - as I
understand it basically gcc although it has been made to build with Intel
compilers
icc once compiled the kernel. But they had to teach it quite a lots of
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
After some massaging, I've succeeded in generating bad code using a
slightly modified MemSetAligned macro (parameters -O2
-fstrict-aliasing): gcc pipelined the x*x around the memset.
As I already explained, we do not care about
Christoph Dalitz wrote:
On Thu, 11 Sep 2003 20:51:24 +0200
Manfred Spraul [EMAIL PROTECTED] wrote:
- OemToChar() and CharToOem() convert all console input/output. In the
long run this might be the better solution, if it works entirely without
user intervention. I'm not sure if it's possible
Peter Eisentraut wrote:
If you can detect that they are different, why can't you adjust the code
page in that case only?
What should we do if we detect that they differ:
- set the console code page to the ansi code page. This has two
drawbacks: It doesn't work with Indic, because Indic
24 matches
Mail list logo
