[sword-devel] thread-safety in libsword?
Troy A. Griffitts
scribe at crosswire.org
Tue Jan 12 00:28:07 MST 2016
Dear Teus,
In what way are you accessing this code in a multi threaded fashion?
Can you produce a small standalone program which exhibits the problem so we might debug?
Thanks for your help improving things.
Troy
On January 12, 2016 12:14:56 AM MST, Teus Benschop <teusjannette at gmail.com> wrote:
>Hi,
>
>The ticket about thread safety exactly describes the problems I am
>seeing :)
>
>The code is this:
>
> sword::SWMgr manager (sword_logic_get_path ().c_str ());
> sword::SWModule *module = manager.getModule (module_name.c_str ());
> if (module) {
> string key = osis + " " + convert_to_string (chapter).c_str () + ":" +
>convert_to_string (verse).c_str ();
> module->setKey (key.c_str ());
> rendering = module->renderText();
> }
>
>Indeed, the crashes relate to "setKey" and "renderText", and not to
>"SWMgr".
>But I am happy to surround the entire block with a mutex, and it's
>working
>fine :)
>Thank you for all your hard work!
>
>Teus.
>
>On Mon, 11 Jan 2016 at 17:33 Troy A. Griffitts <scribe at crosswire.org>
>wrote:
>
>> Hi Teus,
>>
>> Yes, as Greg has pointed out, we've done our best to make it easy to
>> perform multitheaded operations with the library by allowing you to
>> instantiate a new SWMgr for each thread. We don't use threading
>libraries
>> ourself inside the engine to lock critical sections but instead we
>tried to
>> avoid critical sections within one instance of an SWMgr. We allocate
>a
>> distinct instance of SWMgr per thread in many of our friends, e.g.,
>one
>> SWMgr for display and one for search so we can search in a separate
>thread.
>>
>> With a standard threading mechanism included in C++11 we might
>consider
>> conditionally compiling in support to assure some iffy common
>sections of
>> code are in fact safe. I am specifically thinking of junk buffers in
>SWBuf
>> (but I think we cleaned those up) and also FileMgr, which handles
>closing
>> and reopening file handles at the system level when resources are
>tight.
>>
>> On January 11, 2016 5:52:58 AM MST, Teus Benschop
><teusjannette at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> When accessing libsword simultaneously from multiple threads, it
>often
>>> crashes. When surrounding the calls to the library with a mutex.lock
>and a
>>> mutex.unlock at the end, there's no crashes when accessing it in the
>same
>>> situation. I am seeing this on Linux and on the Mac. Should I do
>something
>>> in the library, or make a special call, to make it thread-safe? Or
>is
>>> surrounding the library calls with a mutex the recommended way to
>handle
>>> this?
>>>
>>> Teus.
>>>
>>>
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>sword-devel mailing list: sword-devel at crosswire.org
>http://www.crosswire.org/mailman/listinfo/sword-devel
>Instructions to unsubscribe/change your settings at above page
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20160112/95149d25/attachment-0001.html>
More information about the sword-devel
mailing list