Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] PCNTL compatibility to Windows?

Posted by David Rodrigues 
David Rodrigues
[PHP-DEV] PCNTL compatibility to Windows?
January 22, 2018 01:20PM
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!

--
David Rodrigues
Thomas Hruska
Re: [PHP-DEV] PCNTL compatibility to Windows?
January 22, 2018 05:00PM
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/ms684320(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/ms686219(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/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
David Rodrigues
Re: [PHP-DEV] PCNTL compatibility to Windows?
January 22, 2018 05:20PM
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 <[email protected]>:

> 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
Sorry, only registered users may post in this forum.

Click here to login