php-general Digest 9 May 2011 14:11:17 -0000 Issue 7304

Topics (messages 312725 through 312729):

Re: How to DUMP $_POST parameters to a log file? Very useful and missing in the 
php.net
        312725 by: Peter Lind
        312726 by: Eli Orr (Office)

Re: semaphores are broken
        312727 by: Rasmus Lerdorf
        312728 by: Jeremy Greene

Re: [PHP-WEBMASTER] Simple question
        312729 by: Richard Quadling

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
        php-gene...@lists.php.net


----------------------------------------------------------------------
--- Begin Message ---
On May 8, 2011 1:57 PM, "Eli Orr (Office)" <eli....@logodial.com> wrote:
>
>
> Dear PHP Gurus,
>
> I need dump a $_POST parameters as part of debug process with a client.
> Any know service to make this ?
>
> I know $_POST is an Array but I look for a service function  that can save
the parsed array into a file.
> let say :
>
> $stt = save_POST_into_file ($_POST, $fp);
>

file_put_contents($filename, print_r($array, true));

Regards

--- End Message ---
--- Begin Message ---
Thanks. Great! It works so well !

On 08/05/2011 15:01, Peter Lind wrote:
On May 8, 2011 1:57 PM, "Eli Orr (Office)"<eli....@logodial.com>  wrote:

Dear PHP Gurus,

I need dump a $_POST parameters as part of debug process with a client.
Any know service to make this ?

I know $_POST is an Array but I look for a service function  that can save
the parsed array into a file.
let say :

$stt = save_POST_into_file ($_POST, $fp);

file_put_contents($filename, print_r($array, true));

Regards



--
Best Regards,

*Eli Orr*
CTO & Founder
*LogoDial Ltd.*
M:+972-54-7379604
O:+972-74-703-2034
F: +972-77-3379604

Plaut 10, Rehovot, Israel
Email: _Eli.Orr@LogoDial.com_
Skype: _eliorr.com_

--- End Message ---
--- Begin Message ---
On Fri, May 6, 2011 at 12:57 PM, Jeremy Greene <jer...@zeevee.com> wrote:
> Then.... I find out that sem_acquire() actually returns **OK** when the
> underlying semop call gets an EINTR!!! Holy cow. How can a "php system"
> call loose an error?! That's just crazy.

Generally you don't care about an EINTR on a semop() call. If you do
you will have installed a signal handler to handle that interruption.
The low-level code has:

    while (semop(sem_ptr->semid, &sop, 1) == -1) {
        if (errno != EINTR) {
            php_error_docref(NULL TSRMLS_CC, E_WARNING, "failed to %s
key 0x%x: %s", acquire ? "acquire" : "release", sem_ptr->key,
strerror(errno));
            RETURN_FALSE;
        }
    }

which ignores the EINTR as you can see. If you really want to get in
there to handle the uncaught interruption you can do:

pcntl_signal(SIGEINTR,  function($signo) {
     echo "Interrupted\n";
});
sem_acquire(...);
pcntl_signal_dispatch();

But in general, using semaphores in a Web app is a bad idea. Any sort
of locking is bound to get you in trouble which is also why PHP resets
the semaphore at the end of a request.

Generally you will want to think beyond a single server and look at a
message passing mechanism to communicate between a PHP app and a
server process. I think my favourite way to implement this today is
through ZeroMQ. There is a good guide to it at:

http://zguide.zeromq.org/page:all
http://www.zeromq.org/bindings:php

Or if you want something higher level you could have a look at
Gearman. Your server could register itself as a Gearman worker and you
could use the nice Gearman API to communicate with the server.

-Rasmus

--- End Message ---
--- Begin Message ---
This is on a simple-ish embedded system. And yes, I did see the code --
that's when I kind of choked :) And, yes, I did implement the interrupt
handler, but liked the design that it would just set a sem that the main
loop can wait for. But that means that the main loop is waiting on a sem
that will get and EINTR now and then. So there's the problem.

I have switched to the approach of putting code in the interrupt
handler... which I guess is fine. It's just annoying that I wasted time
with the 1st approach, that I think is a very reasonable design. And, I
have always been hesitant to put much code in an interrupt handler -- I
have always thought that has issues too.

Jeremy

-----Original Message-----
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] 
Sent: Sunday, May 08, 2011 11:38 AM
To: Jeremy Greene
Cc: php-gene...@lists.php.net
Subject: Re: [PHP] semaphores are broken

On Fri, May 6, 2011 at 12:57 PM, Jeremy Greene <jer...@zeevee.com>
wrote:
> Then.... I find out that sem_acquire() actually returns **OK** when
the
> underlying semop call gets an EINTR!!! Holy cow. How can a "php
system"
> call loose an error?! That's just crazy.

Generally you don't care about an EINTR on a semop() call. If you do
you will have installed a signal handler to handle that interruption.
The low-level code has:

    while (semop(sem_ptr->semid, &sop, 1) == -1) {
        if (errno != EINTR) {
            php_error_docref(NULL TSRMLS_CC, E_WARNING, "failed to %s
key 0x%x: %s", acquire ? "acquire" : "release", sem_ptr->key,
strerror(errno));
            RETURN_FALSE;
        }
    }

which ignores the EINTR as you can see. If you really want to get in
there to handle the uncaught interruption you can do:

pcntl_signal(SIGEINTR,  function($signo) {
     echo "Interrupted\n";
});
sem_acquire(...);
pcntl_signal_dispatch();

But in general, using semaphores in a Web app is a bad idea. Any sort
of locking is bound to get you in trouble which is also why PHP resets
the semaphore at the end of a request.

Generally you will want to think beyond a single server and look at a
message passing mechanism to communicate between a PHP app and a
server process. I think my favourite way to implement this today is
through ZeroMQ. There is a good guide to it at:

http://zguide.zeromq.org/page:all
http://www.zeromq.org/bindings:php

Or if you want something higher level you could have a look at
Gearman. Your server could register itself as a Gearman worker and you
could use the nice Gearman API to communicate with the server.

-Rasmus

--- End Message ---
--- Begin Message ---
On 9 May 2011 14:53, Vincent McGinley <vmcgin...@re-thinkitinc.com> wrote:
> Can you remove the @.
>>
>> Do you get an error?
> Tried this and got same result (page loads up halfway and no error message).
>>
>> Can you change the location to "./folder/$Product.php" ?
> Changed path and same result.
>>
>
>> Does the file actually exist?
> Yes. This all worked before. The only variable that has changed is the
> upgrade to php5
>>
>> Is the included file a PHP file?
> Yes
>>
>> If the file is required_once, it can only be used once. Is that the issue?
> I've tried required, include_once, include. The only difference is that
> require and require_once only loads up half the page and inluce and
> include_once loads up the whole page minus the information that the php is
> looking for.
>>
>> include may be a better option here.
>>
>>
>
>
> On 5/9/11 9:24 AM, "Richard Quadling" <rquadl...@gmail.com> wrote:
>
>> On 9 May 2011 13:48, Vincent McGinley <vmcgin...@re-thinkitinc.com> wrote:
>>> Hello I have one line of php code that would switch out information on a
>>> webpage.
>>>
>>>  <?php   @ require_once ("folder/$Product.php");   ?>
>>>
>>> This would pull in a div with an image and paragraph (the file would be
>>> located within the same folder or subfolder). This simple code worked fine
>>> until we upgraded to PHP5. Is there a slight tweak that needs to be done to
>>> the code to get it to work again?
>>>
>>> Any help would be greatly appreciated.
>>>
>>
>> Can you remove the @.
>>
>> Do you get an error?
>>
>> Can you change the location to "./folder/$Product.php" ?
>>
>> Does it now work?
>>
>> Does the file actually exist?
>>
>> Is the included file a PHP file?
>>
>> If the file is required_once, it can only be used once. Is that the issue?
>>
>> include may be a better option here.
>>
>>
>
>

>From conversation webmaster (related to The PHP Group's web servers)
to general (for general PHP support).

Can you add the following to the top of your script ...

<?php
error_reporting(-1); // Report ALL errors, warnings, notices, etc.
ini_set('display_errors', 1); // Display them as part of the output.

// Your code below ...



-- 
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

--- End Message ---

Reply via email to