Re: cvs: php4 /ext/standard file.c

Hi, > The above is not really right; If you check the code of my_write(), > it only uses errno if write() returns 0 or -1, in which case > errno should contain the right error code. > > (I know that we do a check of ENOSCP for all cases, but as this error > is not very likely and the only action we take is to sleep for a short > time and then continue, this is not really fatal). Right, that is the only case. The point here is that my_write retries the write(), possibly generating SIGXFSZ. > my_write() also does a retry until all bytes are written or until > write() returns -1, so it's not likely that it should miss to write > anything. > > Can you give us a scenario when my_write() can fail? There are a couple of system calls which might set errno to ENOSPC: open() link() mkdir() mkfifo() rename() write() sem_init() sem_open() mq_open() rf_create() If such a system call fails and sets errno to ENOSPC and if errno is not set afterwards, and if my_write() is invoked and if there is less room than necessary to write the data to the filesystem, SIGXFSZ will be delivered to the thread of execution during the write() retry. Unless I'm missing something, there is no way to distinguish these cases: First, the thread was interrupted by a signal and some data was already written. A retry is perfectly acceptable. Second, some data was written and the disk has no more space. Retrying the write() causes SIGXFSZ. This ambiguity is caused by write() not setting errno and simply returning the number of bytes written. > The only thing that 'may' conflict with the above in the my_write() > code is that we check errno if write() returns 0. This isn't covered > by your cases, but this is something I have seen happening with > threads on some systems (in which case errno was always set to EINTR). Do you remember on which systems that happened? I've walked through the man pages of HPUX 10.20/11.0, FreeBSD 5.0, SunOS 4.1.3/5.8, Ultrix 4.2, AIX 4.2, and OpenServer 5.0.6. The only thing I could dig up were some references to returning 0, if non-blocking I/O is used. The only irregularity I found is on AIX which optionally returns -1 in the EINTR case, although some data was already written. > Anyway, I can't quickly see any scenario when my_write() would fail without > having a correct my_errno/errno set. Sasha, if you could give us > a scenario that proves me the current code wrong, then we will of > course change it! As I said before, this is a very unlikely case and applies to regular files only. A quick grep through the MySQL sources reveals that there is no apparent handling of SIGXFSZ, so it is possible that, depending on the circumstances outlined above, MySQL might get terminated during my_write (or are you ignoring most signals by default?). - Sascha