Hi Dennis,
I agree with you about Send/PostMessage(). I just don't see why this is
turning into a problem for sqlite - I thought the only rule was that
database handles have to be unique to each thread. So my application posting
the message via PostMessage() has its own database handle - then the
application which receives and handles the posted message in a message
handler - has its own database handle created within the handler itself. So
everywhere it seems there is a uniqe database handle, unless I'm
misinterpreting the rules or what you described? I put down my pseudo code
to illustrate what I'm doing:
app1:
SomeThread()
{
sqlite3 *db = opendatabase();
writesomestuff();
PostMessage(my_other_app, 0, 0);
closedatabase(db);
return 0;
}
app2:
MessageHandlerInMainThread()
{
sqlite3 *db = opendatabase();
ReadDatabaseStuff(db);
closedatabase();
return 0;
}
Thanks!
Mark
On 9/15/05, Dennis Jenkins <[EMAIL PROTECTED]> wrote:
>
> Mark Wyszomierski wrote:
>
> >I traced this error down a bit, it only appears when using windows'
> >PostMessage() to communicate between applications. Both applications have
> >their own database handles for sure. When one app gets some data, it
> simply
> >uses PostMessage() to inform the other app that some data has been
> received.
> >It is at this point that if I try accessing the database in this message
> >handler, the memory leak occurrs. I even took the additional precaution
> of
> >creating an entirely new database handle inside the message handler
> itself.
> >If I replace PostMessage() with SendMessage(), no leak occurrs. However,
> >replacing PostMessage() with SendMessage() would be a huge penalty. Any
> >ideas why there is a problem here?
> > Thanks,
> >Mark
> >
> >
> Unless I'm wrong (he he... tha can happen):
>
> PostMessage simply inserts the "MSG" into the target thread's message
> queue. The target thread's message pump needs to consume that message
> and dispatch it. Remember, message queues are owned by threads, not
> windows. PostMessage is asynchronous.
>
> SendMessage actually dispatches the message to the target window
> handler, but inside the CALLERs thread context. SendMessage blocks
> until the call is completed. The target message handler must be
> reentrant for this to work.
>
>
>
