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

Reply via email to