On Friday 21 December 2012 10:41:59 Jani Ollikainen wrote: > > So, my conclusion would be that it is the code snippet above, and not any > > part of PHP or the kernel, that is at fault. > > Oh? Did I understand you correctly? If you can code PHP that crashes > PHP, it's that codes fault not PHP's fault? I've always thought PHP > to be high level programming language where PHP handles things for > you and you can't code anything that crashes it like that with > bus error?
I understand your sentiment. To follow up the sentiment in code, there would be two options: 1) capture SIGBUS (and SIGSEGV probably, depending on platform), and in the signal handler, to lots of funny dances to guess from the stack what kind of error message would be helpful to the end user or end developer. 2) remove any attempt to use mmap to speed up reading, generally, or as an ini option. I would personally expect mmap-reading not to make a huge difference in performance anyway, as the short segment double buffering that it avoids, will probably be swamped by any kind of parsing of the content anyway. But probably when people went to the lengths of implementing mmap based reading in the PHP core, they had some good reasons to do so... > I think that it should at least gracefully exit, log error, what caused > what and where. Better option would be that it just works. It CANNOT just work. It wouldn't work reliably without any use of mmap, either. Concurrently modifying and reading one and the same file, will always run into consistency problems, and doing that is CERTAINLY the fault of the code that does it. best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
