Hi Umberto, On Fri, Jan 22, 2016 at 9:49 PM, Umberto Salsi <sa...@icosaedro.it> wrote: > thank you very much for the reply, I now start understanding better what > happen and why currently i/o cannot be handled in user's space.
You're welcome. I think you have pointed out important missing parts in PHP. > Rather than an array of error, which might be quite expensive to handle, > why not a simple "char * lasterror" field added to the stream struct, > normally set to NULL, where a description of the last error occurred may > be stored? The high-level functions, that is PHP fopen, fread, fwrite, > fflush, fseek, fclose, may then check that string and, if set, trigger > E_WARNING with a meaningful message after having reset that string back > to NULL again. Many C libraries already provide such error strings, > starting from the same C strerror(). Pgsql's "notice" logging is implemented this way at first. Then I changed it to array of notices recently. (Notice is raised during transaction, for example) It's very difficult or impossible to detect where something wrong happened if there is only the last error. That's the reason why pgsql module is changed to have array of notices. The same would happen in streams, so it's better to store all errors during operation. Zend hash is extremely fast and good enough for logging errors, so we don't have to worry overheads. > > The same should then be done with the filters, which currently only may > return PSFS_ERR_FATAL, but might have their "char * lasterror" string > too with the same purpose. Knowing the exact reason of the failure is > essential to distinguish, for example, a dead disk drive or corrupted file > system, from a bare file mistakenly opened with the wrong decompressor > or a file which was badly encoded. I agree. > > Then all the specific stream and filter implementations can be adjusted > to set that error string; for those still not fixed that string remains > NULL and fopen, ferror, etc. will not report the error just as they do > today, and will be fixed later step by step. Agree here, too. Someone have to volunteer for this. It's not difficult for people on this list. I have too many backlogs for PHP project, so I hope someone volunteers for this. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
