Joshua, I don't think sqlite was designed to be used that way. It would work very well for your persistent data, that is written to disk.
However, not so well using it as an IPC. The database is locked, not the table, row or even page. The entire DB is locked when you write (insert, update or delete) data. IPC, is best done as either Message Queues depending upon your data volumes. Shared memory with appropriate semaphores/ Mutexes. Or even as one person posted Mmap files. You'll stilll need a mutex or a semaphore to write. Ken "Joshua D. Boyd" <[EMAIL PROTECTED]> wrote: I have a system that currently consists of 2 C programs and 3 python programs. Currently the python programs transfer data between themselves via pickles. The C programs transfer data between themselves via streaming structs, and the C programs talk to one of the python programs via a fairly ugly text over socket method. All of the programs are threaded. Of the data being communicated, some of it must also be saved to disk, and other pieces go away after a reset. All told there is only about 4 k of stuff saved. I am wondering about using SQLite to communicate between the programs. I'd use two databases. One on a flash disk for the data that needs to be saved, and the other database would somehow be in a ram disk. Each Db would have 1 table, and the fields would be key, type, val. Most fields would only be written to by one or two sources, but would be read from by nearly all processes. Is this a stupid use of SQLite? I can't quite seem to find anyone using it like this. I am a little concerned about page locking as opposed to row locking, but I think I can work around that. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
