Re: scm_mutex_lock and scm_mutex_unlock

[Marius Vollmer]

Michael Tuexen <address@hidden> writes:

>> I guess the most portable way to get recursive mutexes is to use
>> pthread_mutex_init together with pthread_mutexattr_settype with
>> PTHREAD_MUTEX_RECURSIVE, which is defined in UNIX98.
>
> That sounds good. PTHREAD_MUTEX_RECURSIVE is defined on my system.

Ok.

>> I will make this change and let you know when it is done.

I have committed it, please try.

2005-10-23  Marius Vollmer  <address@hidden>

        PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is not portable enough.
        
        * null-threads.h, pthread-threads.h
        (SCM_I_PTHREAD_RECURSIVE_MUTEX_INITIALIZER): Removed.
        (scm_i_pthread_mutexattr_recursive): New.

        * threads.c (scm_i_pthread_mutexattr_recursive): Declare.
        (scm_i_critical_section_mutex): Do not initialize statically.
        (scm_threads_prehistory): Initialize
        scm_i_pthread_mutexattr_recursive and scm_i_critical_section_mutex
        here.
        
        * eval.c (source_mutex): Do not initialiaze statically.
        (scm_init_eval): Do it here, using
        scm_i_pthread_mutexattr_recursive.

>> In the mean time, could you try to configure with --without-threads?
>
> Done. Same result. Line 2658 of eval.c is not ifdefed, I think. So it
> is always compiled in.

Hmm, --without-threads should make Guile use null-threads.h instead of
pthread-threads.h.  So there don't need to be any ifdefs in eval.c
itself.

It is sometimes tricky to get configuration changes to really take
effect.  To make really sure, you should probably untar the sources
once again into a new directory and build there from scratch.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405