My last message cites some of the peculiarities of POSIX fcntl() locking. Search the SQLite mailing list archives for more detailed info as it pertains to SQLite.
As for having a single unified (locking) model - SQLite already employs such a strategy as best as is possible given the portable nature of the library. Trying to get all versions of UNIX and Windows to play nice when it comes to file locking is no small chore. DRH has done a great job. --- Emerson Clarke <[EMAIL PROTECTED]> wrote: > Im interested to know what those constraints are and why ? > > The only reason i mentioned shared memory is because it provides a > platform and filesystem agnostic way of handling ipc. Obvioulsy i > dont know the ins and outs of the locking process, but i just thought > it would make sense to have a single unified model rather than > different strategies on many platforms. > > On 12/29/06, Joe Wilson <[EMAIL PROTECTED]> wrote: > > --- Emerson Clarke <[EMAIL PROTECTED]> wrote: > > > Developing multithreaded applications is difficult, i wouldnt dispute > > > that. But i do dispute the wisdom of actively making a library > > > incompatible with threads. > > > > "Actively"? That's a bit much. > > > > There are constraints on the ability to pass SQLite connections > > between threads. To be safe, just use the connection on the > > same thread it was created and you'll be fine. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
