Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
User updated by: stefan at whocares dot de
Reported by: stefan at whocares dot de
Summary: fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package: FPM related
Operating System: Linux (Debian for Sparc)
PHP Version: 5.3.3
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
Thank you for your input. Just so I understand better:
You said "in this context is not what we want". Could you clarify that a
bit? As
far as I understand the code (and I don't claim to fully understand it)
it just
checks whether if a specific memory region contains a value of "0" and
if so, it
tries to set it to "1". At least I couldn't find any calls to the atomic
"add"
functions although they are provided for some architectures.
Also you said: "not using 'atomic' operation will be the better approach
for
your scenario". Would you have an example / explanation on how to do
that? I'd
really be interested in that so I could eventually come up with a good
and
working solution.
Previous Comments:
------------------------------------------------------------------------
[2010-11-18 01:53:37] sriram dot natarajan at gmail dot com
there is difference between these 2 instructions:
ldstub -> operates on a 8 byte value
casa -> operates on a 32-bit word
now, if some one wanted to use these instructions to implement a atomic
mutex
lock, then one could argue that both instruction set are
interchangeable. in
this case, that is not the case. hence, i would argue that there is a
valid case
for using this specific 'compare and swap' instruction set.
using 'ldstub instruction set' in this context is not what we want.
few curl or http get requests cannot display the potential race
conditions.
not using 'atomic' operation will be the better approach for your
scenario.
------------------------------------------------------------------------
[2010-11-17 08:27:31] [email protected]
one simple test is to make php core the less as possible. You can create
a file
test.php wich does nothing but an "echo".
Then you stress this page with FPM with ab (ab -c 100 -n 10000
http://ip:port/test.php
While the test is running you check the status page and see how it's
goin' on.
it should be a good primary test.
------------------------------------------------------------------------
[2010-11-17 02:19:15] stefan at whocares dot de
First of all: thanks for not taking my rant badly :)
Of course I can run this code and, well "test" it. I would have been
happier
however if someone besides me had looked over the code and said "yes,
that looks
like it could work" ;)
Right now it *is* running on two ReadyNAS (Sparc) boxes as well as on my
SunFire
280R. It doesn't segfault which to me is a good sign and it's producing
normale
output from the small test scripts I have run. Haven't done extensive
testing so
far but will try running Wordpress and Drupal in the next couple of
days. If
there's any special test you'd like to see me run against the patched
version of
PHP, let me know.
------------------------------------------------------------------------
[2010-11-17 01:18:49] [email protected]
@stefan at whocares dot de
Did you run your patch on a ReadyNAS box ? If you test it and tell us it
works,
there is not reason not to integrate it. As far as I know, it's not been
tested
but for compilation only.
We don't want to leave someone behind, but as pierre told you there is
priorities.
We'll be glad if you help us.
------------------------------------------------------------------------
[2010-11-17 01:16:15] [email protected]
and I was wiling to write arch, not OS....
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53310
--
Edit this bug report at http://bugs.php.net/bug.php?id=53310&edit=1
