scm_mutex_lock and scm_mutex_unlock

scm_mutex_lock and scm_mutex_unlock

[Michael Tuexen]

Dear all,

I'm trying to compile guile-1.7.2 on Mac OS X 10.3.9. The  compilation
breaks because scm_mutex_lock and scm_mutex_unlock are used in
libguile/arbiters.c but the compiler and I can not find a definition
of those functions. Where are they defined?

Best regards
Michael



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_mutex_lock and scm_mutex_unlock

[Marius Vollmer]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:

> I'm trying to compile guile-1.7.2 on Mac OS X 10.3.9. The  compilation
> breaks because scm_mutex_lock and scm_mutex_unlock are used in
> libguile/arbiters.c but the compiler and I can not find a definition
> of those functions. Where are they defined?

That's a bug in guile 1.7.2 that has been fixed in CVS:

2005-03-18  Kevin Ryde  <user42@zip.com.au>

	* arbiters.c (FETCH_STORE) [generic C]: Should be
	scm_i_scm_pthread_mutex_lock/unlock now.  Reported by Ludovic Courtès.

You could try a recent 'unstable' snapshot:

ftp://ftp.dt.e-technik.uni-dortmund.de/pub/guile/snapshots/guile-core.unstable.tar.gz

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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_mutex_lock and scm_mutex_unlock

[Michael Tuexen]

Hi Marius,

thanks, that works. It now stops at

eval.c:2658: error: `PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP' undeclared  
here (not in a function)

Any idea, how to fix that? I'm trying to compile it on Mac OS X 10.3.9.

Best regards
Michael

On Oct 23, 2005, at 14:28 Uhr, Marius Vollmer wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
>> I'm trying to compile guile-1.7.2 on Mac OS X 10.3.9. The  compilation
>> breaks because scm_mutex_lock and scm_mutex_unlock are used in
>> libguile/arbiters.c but the compiler and I can not find a definition
>> of those functions. Where are they defined?
>
> That's a bug in guile 1.7.2 that has been fixed in CVS:
>
> 2005-03-18  Kevin Ryde  <user42@zip.com.au>
>
> 	* arbiters.c (FETCH_STORE) [generic C]: Should be
> 	scm_i_scm_pthread_mutex_lock/unlock now.  Reported by Ludovic Courtès.
>
> You could try a recent 'unstable' snapshot:
>
> ftp://ftp.dt.e-technik.uni-dortmund.de/pub/guile/snapshots/guile- 
> core.unstable.tar.gz
>
>
> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_mutex_lock and scm_mutex_unlock

[Marius Vollmer]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:

> eval.c:2658: error: `PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP'
> undeclared  here (not in a function)
>
> Any idea, how to fix that? I'm trying to compile it on Mac OS X 10.3.9.

Hmm.  PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP seems not to be portable
enough.  (I know that the _NP suffix means 'non-portable'...)

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.

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

In the mean time, could you try to configure with --without-threads?
With that option, guile should make no reference to pthread things.

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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_mutex_lock and scm_mutex_unlock

[Michael Tuexen]

Hi Marius,

see my comments in-line.

Best regards
Michael

On Oct 23, 2005, at 22:13 Uhr, Marius Vollmer wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
>> eval.c:2658: error: `PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP'
>> undeclared  here (not in a function)
>>
>> Any idea, how to fix that? I'm trying to compile it on Mac OS X 
>> 10.3.9.
>
> Hmm.  PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP seems not to be portable
> enough.  (I know that the _NP suffix means 'non-portable'...)
>
> 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.
>
> I will make this change and let you know when it is done.
Thank you very much.
>
> 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.
> With that option, guile should make no reference to pthread things.
Does not work, I think. And would not help... I'm trying 1.7.2, because
I want to use pthreads...
>
> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_mutex_lock and scm_mutex_unlock

[Marius Vollmer]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> 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  <marius.vollmer@uni-dortmund.de>

	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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_mutex_lock and scm_mutex_unlock

[Michael Tuexen]

Hallo,

I tried the old version with --without-threads and it worked.

How can I try the new version? the guile-core-unstable.tar.gz
is still the old version...

Best regards
Michael
On Oct 23, 2005, at 23:15 Uhr, Marius Vollmer wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> 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  <marius.vollmer@uni-dortmund.de>
>
> 	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
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_mutex_lock and scm_mutex_unlock

[Marius Vollmer]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:

> I tried the old version with --without-threads and it worked.

Ok!

> How can I try the new version? the guile-core-unstable.tar.gz
> is still the old version...

You can wait for the snapshots to catch up (should happen in a day or
so), or you can check out the sources from CVS, see 

    http://www.gnu.org/software/guile/anon-cvs.html

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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel