On Fri, 2010-04-30 at 18:34 +0200, Julien Kerihuel wrote:
> Attached is the modified concurrent_test.c with mutex support.
>
> I basically lock the mutex (one per session) prior any MAPI call and
> unlock it after the call returns.
>
> This patch is really 'quick and dirty' but shows the problem can be
> fixed.
Hi,
yup, I noticed a lock&lock in monitorB, where it should be lock&unlock,
but anyway, as the MonitorNotification function is blocking, then the
lock is "never" released, thus the get_inbox function never continues
its duty. It's technically the same as the old notification sample. :)
> The way to proceed now is to add a mutex to the session context,
> initialize it and do the lock/unlock where necessary within libmapi
> stack.
>
> Initially I thought a lock/unlock enclosing dcerpc_EcDoRpc would be
> enough, but I guess we'll need macro instead to also enclose memory copy
> from the mapi_response pointer.
The idea is right, there should be done some locking in libmapi to
prevent concurrent access on objects which cannot handle it, like
connections and such. You mentioned on IRC: add one lock for any
provider within a session (emsmdb, nspi and rfr potentially).
> Now regarding the change, we can either add libpthread a dependency to
> libmapi or offer a --with-pthread compilation option at build time and
> #ifdef/#endif whenever we use code related to thread.
>
> I'm not sure complicating the code to offer thread/non-thread support is
> truly worthwhile ... but maybe this makes sense for some platforms?
I believe adding locking is correct, and doesn't make much sense to have
it as a compiler switch, maybe only if it's enabled by default and the
respective platform will disable it on its purpose, with the known issue
of potentially breaking code due to concurrent access to the session
objects in particular case(s).
Thanks and bye,
Milan
_______________________________________________
devel mailing list
devel@lists.openchange.org
http://mailman.openchange.org/listinfo/devel
