From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Cc: guile-devel@gnu.org
Subject: Re: scm_mutex_lock and scm_mutex_unlock
Date: Mon, 24 Oct 2005 14:45:48 +0200 [thread overview]
Message-ID: <ca9e71cdfb9a64d488c6d43c8eb4e417@lurchi.franken.de> (raw)
In-Reply-To: <873bmsrl49.fsf@zagadka.de>
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
next prev parent reply other threads:[~2005-10-24 12:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-22 15:07 scm_mutex_lock and scm_mutex_unlock Michael Tuexen
2005-10-23 12:28 ` Marius Vollmer
2005-10-23 15:40 ` Michael Tuexen
2005-10-23 20:13 ` Marius Vollmer
2005-10-23 20:53 ` Michael Tuexen
2005-10-23 21:15 ` Marius Vollmer
2005-10-24 12:45 ` Michael Tuexen [this message]
2005-10-24 19:17 ` Marius Vollmer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca9e71cdfb9a64d488c6d43c8eb4e417@lurchi.franken.de \
--to=michael.tuexen@lurchi.franken.de \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).