opened
sanmai
username_0
What about alternatives? All alternatives presume that there will be the above warning added that will...

- Ask a user to set a memory limit in the global `php.ini`. This is unacceptable because nobody should be forced to change `php.ini` if a program can find a way to work without a change.

- Suggest a user set a memory limit on the command line with `php -dmemory_limit=128M infection.phar`. This is unsatisfactory because in this case the memory limit will be applied not only to mutations process but to mutation itself. Mutation is a well-written CLI command, it does not require any memory limits by itself.

- Enforce memory limits with `ulimit`, `softlimit`, and similar tools. This is undesirable because it will require a constant care from a user.

- Another option is to add 'badness' points to the mutations processes by writing to `/proc/<pid>/oomadj`. This is Linux-specific and will not help users on other platforms. This also won't make Infection faster or more reliable because it won't have a choice on killed processes.

- Yet another option is to monitor a derivative of a mutation process memory usage growth. This will be very OS specific and bear other drawbacks compared to imposing a straight-on memory limit. 

All alternatives are worse than this proposal because...
 
- They try to impose limits on the Infection itself. There's no evidence this is necessary. 
- They fail to deliver a better usability and bear no promise of enhanced adoption rates.
- They require more effort from the user, and require more care, on the contrary with this proposal.
- They make Infection more difficult to operate than it is now.

### What next?

Since there was a heated discussion on how to proceed with a similar proposal, I will not move forward with more work on this PR beyond current PoC unless there is a consensus. I see no point in spending hours and hours only to have your work thrown into a bin. Please tell me if there's something in this proposal, or if this proposal is not worthy and got to be rejected.
Add a mandatory memory limit for mutation sub-processes
issue
created
borNfreee
username_1
Is it still relevant when https://github.com/infection/infection/pull/258 is merged?
comment
created
borNfreee
username_1
comment
created
sanmai
username_0
Don't be sorry. What I meant is that I'm really serious about the issue with memory. 

This PR is actually an RFC, but in a proof-of-concept pull-request style. I'm not a big believer in a RFC-without-POC type of thing, as you can imagine.

And yes, #258 is worse than this one but works for me, as they say. Closing it for now.
comment