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 <thru...@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
