[sword-devel] thread-safety in libsword?

[Troy A. Griffitts]

Dear Костя and Teus,

Thank you for your help trying to track this down. Teus, your code shows that you are indeed creating a separate SWMgr for each thread, as the SWMgr object is a local variable in that function.

Костя, thanks for the backtraces. I remember talking about this a long while ago with you and thought you helped me clear up some statics that were causing trouble. I'll have a look at your backtracks when I get to my computer.

Thanks again, both of you, for your time and assistance with this.

Troy

On January 12, 2016 4:06:45 AM MST, "Костя Маслюк" <kostyamaslyuk at gmail.com> wrote:
>http://www.crosswire.org/tracker/browse/API-166 yet contain example and
>backtraces, is it something wrong with they?
>
>2016-01-12 11:28 GMT+04:00 Troy A. Griffitts <scribe at crosswire.org>:
>
>> 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.
>>
>> _______________________________________________
>> 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/914b3437/attachment-0001.html>