Re: accessing persistent from multiple threads
One thing my code didn't account for was exceptions. You most likely
want to catch any exception inside fullAction and then return it to
the caller, either by having something like `Either SomeException a`
or just by rethrowing it.
On Sun, Jan 8, 2012 at 12:04 AM, Rian Hunter <rian@...> wrote:
> Haha this is great. The trick here is you concatenated the action that writes the mvar with the input action
to keep the chan of type (). I was instead passing the reply mvar over the channel and expecting the worker
thread to write to it explicitly. Thanks for this Michael!
> On Jan 7, 2012, at 1:35 PM, Michael Snoyman <michael@...> wrote:
>> On Fri, Jan 6, 2012 at 7:37 PM, Rian Hunter <rian@...> wrote:
>>> On Jan 5, 2012, at 8:55 PM, Michael Snoyman wrote:
>>> Actually, I don't think this is necessary at all. runPool ensures that
>>> a single SQLite connection is being used by only a single thread. I'm
>>> pretty certain that SQLite can handle multiple connections to a single
>>> you're right it isn't strictly necessary but what i don't want is for one
>>> connection to see an intermediate state during a transaction while another
>>> thread is modifying the database row by row. it turns out that even though
>>> sqlite allows concurrent readers & writers, the default isolation level is
>>> actually SERIALIZABLE
>>> (http://www.sqlite.org/pragma.html#pragma_read_uncommitted) which is exactly
>>> what i want. i may get spurious SQLITE_BUSY exceptions if i have two
>>> concurrent writers but that's not a big deal. i'll keep things as they are
>>> for now.
>>> still... if you had to solve a problem like this, for instance on an
>>> in-memory database. is there a cleaner way to do it than using Data.Dynamic?
>> Just to be clear: are you talking about some kind of an API where you
>> would register that an action should occur, and then you get back a
>> future (i.e., promise) of a result?
>> I was about to give some vague description of how to do this, but then
>> I realized that it was far too much fun to actually write all the
>> code. It hasn't been tested outside of compiling it, but it should be