I have been tracing the source of a low-occurrence anomaly in my C# application, running on Linux 2.6 under Mono. My application is using Robert Simpson's SQLite .NET adapter + SQLite 3.7.5. After I resolved my own bug, which prevented me from seeing the exception thrown by System.Data.SQLite, I found out that SQLite was bailing due to SQLITE_IOERR. I recompiled SQLite to make extended result codes on by default (not sure if I could do this from System.Data.SQLite). The extended result code was consistently SQLITE_IOERR_WRITE. I found 2 placed in the source that returned this error on the UNIX system: fcntlSizeHint and unixWrite. A few lines of code later, I narrowed it down to unixWrite. So as a quick patch I modified the return statement from (SQLITE_IOERR_WRITE) to (SQLITE_IOERR_WRITE | (pFile->lastErrno << 16)). The result was errno 4, which according to my flavor of Linux is EINTR.
So, I wanted to ask if my analysis seem correct? If write() is interrupted by a signal, then an SQLITE_IOERR is generated. With that being said, would I be out of line to suggest that this is an oversight? Would it be acceptable to ask SQLite to detect EINTR and retry the write? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
