[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Aspell-user] Thread Safety Question
From: |
Christoph Hintermüller |
Subject: |
Re: [Aspell-user] Thread Safety Question |
Date: |
Wed, 19 Oct 2005 22:32:08 +0200 |
User-agent: |
KMail/1.8 |
Hi
Am Mittwoch, 19. Oktober 2005 21:18 schrieb Jake Goulding:
> Is the current version (0.60.3) thread safe? Browsing the manual for
> aspell has these two relvant sections:
>
> 6.1.4 Notes About Thread Safety
>
> Aspell should be thread safe, when used properly, as long as the
> underlying compiler, C and C++ library is thread safe. Aspell objects,
> including the AspellSpeller class, should not be used by multiple
> threads unless they are protected by locks or it is only accessed by
> read-only methods. A method is read-only only if a |const| object is
> passed in. Many methods that seam to be read-only are not because they
> may store state information in the object.
>
>
> D.1.1 Things that need to be done
>
> * Make Aspell *Thread safe*. Even though Aspell itself is not
> multi-threaded I would like it to be thread safe so that it can be
> used by multi-threaded programs. There are several areas of Aspell
> that that are potently thread unsafe (such as accessing a global
> pool) and several classes which have the potential of being used
> by more than one thread (such as the personal dictionary). /[In
> Progress]/.
>
> Which of these two paragraphs should I trust?
>
Both as they say the same. Aspell is only partially thread safe. If used in a
multythreaded aplication it requires a sole and unique wrapper thread which
handles all the aspell stuff and communicates with all the other threads
needing support from aspell. Such a thread has to implement and handle all
the access controls, queue the requests from the different threads, send them
sequentially to aspell and properly redistribute the output from aspell back
to the threads.
Alternatively all threads using aspell have to communicate with each other by
some aspell acess protocol/signaling to ensure that no other thread tries to
use aspell while it is in use by any thread.
Aspell itself does not provide any access control nor has it any mechanism for
request sheduling ....
cu
Xris
>
> _______________________________________________
> Aspell-user mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/aspell-user
>
>