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
