Re: [help-serveez] Thread safety

[Andreas Rottmann]

stefan <address@hidden> writes:

> On 6 Dec 2002, Andreas Rottmann wrote:
> 
> > > The problem is: Serveez does not use any thread API.
> > >
> > > Therefore we need a sleep()'y loop (waiting for the (access) variable) or
> > > something.  Any better idea?
> > >
> > This would be horrible IMO. I'd simply make it possible to compile
> > serveez against POSIX threads (configure option), and then use a
> > mutex.
> 
> Personally I do hestitate putting (POSIX) threads into the Serveez API.
> But if I ever get convince to do so I propose this:
> 
I don't propose adding thread primitives to the Serveez API. I just
want Serveez to use a (= POSIX) thread API to make certain functions
(like svz_log) thread-safe.

>  * create 'threads.h' and 'threads.c' into libserveez
>  * use system dependent #ifdef #endif's
>  * supply a system independent interface like:
>       - svz_mutex_create (char *name)
>       - svz_mutex_lock (char *name)
>       - svz_mutex_unlock (char *name)
>       - svz_mutex_destroy (char *name)
>    The mutices in serveez should be referenced by a unique name and should
>    be managed in a 'svz_hash_t'.
>  * if no thread/mutex API is available on the system the functions should
>    be empty and thread-safety goes to waste
>  * for GNU/Linux I proprose the pthread API
> 
I think PThreads are standardized/implemented on enough platforms that
it doesn't make sense to create yet another built-upon pthreads thread
API, but that's just my opionion, YMMV... I think it would make sense
to use pthreads if available, as there are implementations for nearly
all of the Unices (and if there is no implementation, one could use
GNU pth's pthread emulation) and also for Win32.

> > > Actually I forgot why svz_config is not static...
> > >
> > Is it used from `outside' of serveez/libserveez?
> 
> The 'svz_config' is not static because it is used inside libserveez across
> object (.o) boundaries.  It is a unique global symbol.
> 
Hmm, would i guess then it would be not really nice to have to go
through accessor functions. Maybe access could be guarded by
svz_config_lock()/svz_config_unlock() (which would use a static
mutex).

Regards, Andy
-- 
Andreas Rottmann         | address@hidden        | address@hidden | 
address@hidden
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62