Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101655
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <630ac0e1-692b-ae0b-54f3-94da6f9df7d9@cubiclesoft.com>
References: <CAEsg9X1kadEkKxTh2ysaJU7RKb106yhfLtj8mpsCXFDp2-AVsw@mail.gmail.com>
 <630ac0e1-692b-ae0b-54f3-94da6f9df7d9@cubiclesoft.com>
Date: Mon, 22 Jan 2018 14:10:17 -0200
Message-ID: <CAEsg9X1DRWwnWtWJHFJYA1R3c81cn7yGmPaBo-tewuXf72-M1A@mail.gmail.com>
To: Thomas Hruska <thruska@cubiclesoft.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a1134e22cb99d9405635fabb1"
Subject: Re: [PHP-DEV] PCNTL compatibility to Windows?
From: david.proweb@gmail.com (David Rodrigues)

--001a1134e22cb99d9405635fabb1
Content-Type: text/plain; charset="UTF-8"

Wow!

Thanks for this very detailed anwser!

I really could not understand everything because of my limitation about
this topic, but I really could understand the reasons that it will not
works fine and I agree that, for now, it is not a good idea (because of
hackish way to implement it, mainly).

Thank you!

2018-01-22 13:58 GMT-02:00 Thomas Hruska <thruska@cubiclesoft.com>:

> On 1/22/2018 5:16 AM, David Rodrigues wrote:
>
>> Hello.
>>
>> I know that PCNTL extension is not compatible with Windows, but I can't
>> found the reason for that.
>>
>> I mean, I know that it is a feature that Unix system could provide in a
>> better way (natively I guess). But "why" Windows could not emulates this
>> features and have a PCNTL support too? Even if it had a lower performance,
>> it still could be useful on testing environments.
>>
>> So the question is: there are some hard limitation to it be impossible or
>> would it be kind of a "lack of interest"?
>>
>> Thanks!
>>
>
> Windows is a completely different OS.
>
>
> Windows does not have signals:
>
> https://stackoverflow.com/questions/3333276/signal-handling-on-windows
>
> That rules out all of PCNTL's signal handling support, which is 11 out of
> the 22 functions that PCNTL has (I'm excluding aliases in that count).
> Simply being unable to implement 50% of the functions is not a good start
> to a successful port.
>
>
> Windows does not have fork/exec.  Although there are non-starter
> "solutions":
>
> https://en.wikipedia.org/wiki/Fork%E2%80%93exec
>
> Windows starts and manages processes VERY differently from *NIX.  Cygwin
> apparently has a working fork/exec implementation for Windows, but Cygwin
> is GPL.  Any implementation would have to be clean-roomed for PHP and would
> likely involve ugly things such as copying raw memory from one process
> space to another and/or using undocumented Zw kernel calls, all of which
> can change dramatically between OS releases.
>
>
> Windows processes are referenced by HANDLE, not process ID.  Referencing
> by process ID might seem doable with OpenProcess():
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms6
> 84320(v=vs.85).aspx
>
> But even PROCESS_QUERY_LIMITED_INFORMATION access might be denied when
> attempting to open the handle.  Even for child processes.  It happens when
> a process changes its own DACLs specifically to block
> OpenProcess()/OpenThread() calls.  Although the approach can't readily
> block SeDebugPrivilege, you don't ever want PHP core/userland running with
> SeDebugPrivilege.
>
> A PHP implementation might work fine for direct children for most
> use-cases where the HANDLEs are kept around, but grandchildren might not be
> accessible.  Also, there's already the "proc_..." series of functions for
> handling child processes, which more correctly uses generic resource
> handles instead of integers.
>
>
> Windows does not know what a zombie process is.  Unlike *NIX, Windows
> doesn't have a rule that a child must have a parent and that the parent
> must wait on each child to exit before the parent itself exits.  Windows
> processes can exit whenever they want and the kernel cleans up after the
> process.
>
>
> Windows does have a few process priorities:
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms6
> 86219(v=vs.85).aspx
>
> However, you can do things such as completely freeze up Windows -
> including the keyboard processing buffer and mouse cursor - with a process
> priority of REALTIME_PRIORITY_CLASS and a "while (1)" loop where the
> specified process will get *exclusive* scheduling by the kernel (i.e. a
> reboot is the only option).  It's a little-known security
> vulnerability-waiting-to-happen bit of Windows API history.
>
>
> I dunno.  When all is said and done, pcntl_getpriority(),
> pcntl_setpriority(), pcntl_get_last_error(), pcntl_strerror(), and maybe
> pcntl_wait() and associated status functions are about the only functions
> that can be somewhat cleanly implemented for Windows using Windows APIs
> with minimal effort.  pcntl_waitpid() might be able to be implemented with
> some effort but possibly not work properly for pids less than 1 (with all
> the usual waitpid() caveats).  The signal handling are simply not doable.
> Implementing fork/exec doesn't make a lot of sense - a lot of effort for
> little gain.
>
> --
> Thomas Hruska
> CubicleSoft President
>
> I've got great, time saving software that you will find useful.
>
> http://cubiclesoft.com/
>
> And once you find my software useful:
>
> http://cubiclesoft.com/donate/
>



-- 
David Rodrigues

--001a1134e22cb99d9405635fabb1--