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 <scr...@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 <teusjanne...@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 <scr...@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 <
>>> teusjanne...@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@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@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@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@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
