php-general Digest 15 Nov 2011 11:50:13 -0000 Issue 7568

Topics (messages 315679 through 315681):

Problems with proc_open and getmypid
        315679 by: Francisco M. Marzoa Alonso

Re: Novice MySQL problem
        315680 by: Tommy Pham

Re: problem with sending AT command in php
        315681 by: a dehqan

Administrivia:

To subscribe to the digest, e-mail:
        [email protected]

To unsubscribe from the digest, e-mail:
        [email protected]

To post to the list, e-mail:
        [email protected]


----------------------------------------------------------------------
--- Begin Message ---
Hello,

I'm developing a PHP application that runs on GNU/Linux with php cli. A
process must launch another one and store its pid, so I use proc_open
and then proc_status to achieve that.

The child process must also get its own pid and write it down to a file.

After that, the calling process should compare both pids and they should
match, but in fact they shoudln't.

The problem is that when calling to proc_open like:

$res = proc_open ("/usr/bin/php proc2.php", array(), $pipes);

Two processes are created, one for the sh shell that launchs the php
interpreter, and another for the php interpreter itself. Also, it seems
like proc_get_status($res) returns the status of the sh, while getmypid
in the second process returns the pid of the php interpreter.

I wonder if there's anyway of do something of these:

a) Get the pid of the php interpreter on proc_open instead of the sh one
on the parent process, or...

b) Get the pid of the sh process instead of the php interpreter on the
child process.

Or any manner in which two pids matches.

Thanks a lot in advance,

--- End Message ---
--- Begin Message ---
On Mon, Nov 14, 2011 at 4:11 AM, Stuart Dallas <[email protected]> wrote:
> On 14 Nov 2011, at 11:47, Jim Giner wrote:
>
>> Actually, no it doesn't,  since I have a well-developed sense of all of
>> that, but that's not helping to answer the OP's question now, is it?  Stay
>> on point.
>
> The OP's problem is solved, so the point is no longer relevant.
>
> I'm curious to know what your "well-developed sense of all of that" does when 
> in lieu of auto-incrementing fields, and why.
>
> The only legitimate reason I've ever come across to avoid them is when you 
> expect to need to partition data across multiple master DB servers. Is this 
> why you avoid them?
>
> -Stuart
>
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/
>
>

Even with clustering, not comparing inherent clustering technique
between RDBMSes, consider the following (MySQL) table example:

CREATE TABLE `my_cluster_sample` (
 `pkID1_AutoInc` bigint(11) NOT NULL AUTO_INCREMENT,
 `pkID2_SrvrID` int(11) NOT NULL DEFAULT '1' COMMENT 'Use # of
designated server ID',
 `name` varchar(50) NOT NULL,
 PRIMARY KEY (`pkID1_AutoInc`,`pkID2_SrvrID`)
)

The only reason that I see where not to use integer types with auto
increment for PK is when you have an insane _LARGE_ number of rows, in
any given DB instance/server.  Then, the integer type no longer
applies and the use of GUID/UUID or other surrogate types comes in,
aside from getting into hot debate/discussion about pros & cons of
natural vs surrogate keys even if you don't have large amount of data
;)

Regards,
Tommy

--- End Message ---
--- Begin Message ---
\n is for Linux
\r is for Windows

On 11/14/11, Richard Quadling <[email protected]> wrote:
> On 12 November 2011 20:02, a dehqan <[email protected]> wrote:
>> dio_write($handle, 'AT') & dio_write($handle, "AT") make firefox times out
>> on Waiting for localhost ... .
>> But dio_write($handle, "AT\n") makes it prints AT exactly the same command
>> or  Atttt > Atttt , ..
>>
>> On Sat, Nov 12, 2011 at 10:02 PM, Negin Nickparsa
>> <[email protected]>wrote:
>>
>>> are you sure about ATD03518726535\n?
>>>
>>>  can you try if ( dio_write($handle, 'AT') )?
>>>
>>
>
> Don't use \n, use \r.
>
> http://en.wikipedia.org/wiki/AT_commands#Example_session
>
>
>
> --
> Richard Quadling
> Twitter : EE : Zend : PHPDoc : Fantasy Shopper
> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea :
> fan.sh/6/370
>

--- End Message ---

Reply via email to