Would this also explain the 'corruption' in the evaluator we have been
seeing (bad bindings at .. )?
I don't think so; in fact, I just got one of those errors while
looping your test code. I think it's something else, unrelated to the
patch I just sent in. I'll keep looking at it. You have
I've seen `srfi-18.test' hang from time to time, but not often enough to
give me an incentive to nail it down. :-( I don't think it relates to
Han-Wen's GC changes.
Crap, I'm seeing some lockups now, too. Sorry, guys. I'm debugging,
but don't let that stop you from investigating as well.
Hmmm... I don't recall seeing those when I was writing that test
suite. Just to be clear, were you getting those errors before making
your changes?
On Sat, Aug 16, 2008 at 2:21 PM, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
Hi there,
I have finished my GC cleanup. It mostly seems to work,
I'm still not convinced by the last option. Given the above, Option 2
(that is, writing our own, preferably in Scheme) seems to be the safest.
Hopefully this isn't too much work, but the above quote indicates that
we should be careful about performance. ;-)
Would you like to try doing it?
Yikes, didn't mean for it to take this long. Work got crazy, then my
laptop died. At any rate, find attached a draft of an SRFI-18
section. Let me know what you think. Apologies in advance for any
punctuation screw-ups or missing spaces.
On Mon, Jun 2, 2008 at 12:48 AM, Julian Graham [EMAIL
BTW, it'd be nice to have an SRFI-18 node in the manual. :-)
Working on it... Should have something for you in a few days.
Regards,
Julian
. (That handler's purpose is to notify future joiners of the
cancellation event, which is unnecessary if the thread is never
canceled.)
Regards,
Julian
From 75c5ec7b90a5cb1057520a8051ce5033212c77be Mon Sep 17 00:00:00 2001
From: Julian Graham [EMAIL PROTECTED](none)
Date: Sat, 24 May 2008 19:11:12
It looks like the license terms would indeed allow us to do that. I'm
not sure whether there's a precedent including non-LGPL SRFI code as is,
though.
Well, it wouldn't have to be 100% as-is -- aside from adding the
module declaration, there are some things I wouldn't mind tweaking a
bit,
Hi everyone,
While I was testing and debugging some of the SRFI-18 code that Neil
and I were working on, I noticed a deadlock that happens in
scm_join_thread_timed. I'm pretty sure it affects the 1.8 codebase as
well, although it's probably more common when doing timed joins.
Thread joining in
! Thank you for your continued patience.
Regards,
Julian
From 75e5e5c7aad78876fb9e4a2c1523491f58985917 Mon Sep 17 00:00:00 2001
From: Julian Graham [EMAIL PROTECTED](none)
Date: Thu, 15 May 2008 00:50:50 -0400
Subject: [PATCH] Scheme SRFI-18 implementation and tests file
---
srfi/ChangeLog
Any updates / thoughts on the patch? I'd welcome any comments or
revisions you guys'd like to make. (I'd also be happy to write up a
NEWS file entry, if you're waiting for one...)
Regards,
Julian
Find attached a patch (in two parts -- sorry, still getting used to
git) to the core
Looking at SRFI-1 specifically, the spirit is apparently to phrase
things in a way that allows implementations to not actually check
whether arguments are proper lists when proper lists are expected (see,
e.g., [0, 1]).
Great links -- I had no idea this was such a contentious topic!
The probably is that `SCM_VALIDATE_LIST' uses `scm_ilength ()', which
attempts to traverse the list it's given. Thus, it is undesirable to
use it here (and in many other places actually).
Instead, I propose the following patch, which doesn't add any list
traversal but doesn't catch
587b22534a40e16adee5f06e70f4d2b633142054 Mon Sep 17 00:00:00 2001
From: Julian Graham [EMAIL PROTECTED](none)
Date: Mon, 28 Apr 2008 00:32:47 -0400
Subject: [PATCH] fix segfault in scm_srfi1_partition on non-list input
---
srfi/ChangeLog |5 +
srfi/srfi-1.c |3 ++-
2 files changed, 7 insertions(+), 1
Hey, cool -- this will be really handy.
I'll look at cond-expand and require-extension. And unless anyone
objects, I'd like to take a stab at adding SRFI-89 and SRFI-90.
Regards,
Julian
On Sat, Apr 26, 2008 at 3:35 PM, Ludovic Courtès [EMAIL PROTECTED] wrote:
Hi,
FYI, I added this tiny
I'd be down! This sounds like a great project.
On Thu, Apr 24, 2008 at 3:39 PM, Andy Wingo [EMAIL PROTECTED] wrote:
Hello,
So long in the past, it seemed that Keisuke's Guile-VM would mature and
replace the existing scm_ceval(). Everyone was down with it: Marius,
Mikael, etc. But it
I think now is a good time so I just committed the attached patch.
Yay! Thanks, Ludovic.
Now, we should do something about `cond-expand' and `require-extension'.
For the former, we should probably look at the current value of
`(read-options)', but that requires changing the
Hi Ludovic (or whomever this may concern),
I checked out the repository from git last night and tried to build,
but autogen died with the following error:
configure:5524: error: possibly undefined macro: gl_HEADER_STRING_H_DEFAULTS
I'm guessing this has something to do with gnulib, but I'm not
I also see no problem - in API terms - with un-ifdefing
scm_mutex_owner (and scm_mutex_level, while we're there). Could you
just review, though, whether you're happy with their implementation?
In particular, should these functions lock and unlock m-lock?
Given that SCM is supposed to be
Any updates on this? I know you guys are busy with the repository,
but I'm pretty close to having the Scheme implementation for SRFI-18
finished. Like I said, I think enabling scm_mutex_owner would allow
me to proceed, but I don't want to un-ifdef it without knowing why it
was disabled in the
Hi Neil et al.,
Cool -- I'll set up make-mutex for Scheme, and for C as described
above. Let me know if that's not okay.
All sounds perfect to me.
Find attached the latest revision of the core changes for SRFI-18
support. Key changes between this revision and the last are:
*
retrieving revision 1.357
diff -a -u -r1.357 ChangeLog
--- doc/ref/ChangeLog 1 Feb 2008 21:02:15 - 1.357
+++ doc/ref/ChangeLog 11 Feb 2008 02:36:49 -
@@ -1,3 +1,11 @@
+2008-02-10 Julian Graham [EMAIL PROTECTED]
+
+ * api-scheduling.texi (Threads): Add documentation for new
+ functions scm_thread_p
For join-thread, sure. What about scm_join_thread? Sorry if I'm
being obtuse, but my understanding was that you didn't want anything
like scm_join_thread_timed and that changing the signature of
scm_join_thread was out of the question. (Or should this enhancement
only be exposed in
As previously discussed, I think it's better for the core behavior to
be defined - i.e. by signaling some kind of error - than undefined as
it is now.
I suggest we introduce 'locking-abandoned-mutex-error as a new throw
key, and fat_mutex_lock() can throw that. That's then trivial for the
Let me know if I've missed anything.
I don't think so, and I plan to apply this very soon. I've found a
reliable recipe for reproducing the critical section problem: if a
scm_i_gc call is added to make_jmpbuf (), like this:
Excellent -- I'll let you know if I can think of a deterministic
On Jan 24, 2008 8:38 PM, Julian Graham [EMAIL PROTECTED] wrote:
- we apply the generic / bug fix patch that you already posted, except
without the extra thread_admin_mutex locking (which I think we
concluded we can't justify) - that will be to HEAD
Agreed, though see below
- we apply the generic / bug fix patch that you already posted, except
without the extra thread_admin_mutex locking (which I think we
concluded we can't justify) - that will be to HEAD
Agreed, though see below...
- I'll have a go at devising a test for the critical section in
Hi Neil,
NB I have an orthogonal concern here (i.e. possibly yet another issue
with the current code!): If a thread that was running in Guile mode
called scm_leave_guile() to do non-guile stuff for a while, and is
still outside Guile mode, shouldn't it have been removed from the
all_threads
Off-topic, but has there been any discussion of moving Guile to LGPLv3?
On Jan 20, 2008 4:13 PM, Neil Jerram [EMAIL PROTECTED] wrote:
I've just received some queries about Guile's licensing from the FSF
folks. I think all of the following are just oversights, but if
anyone else has any input
Hi Neil,
OK. While looking through the docs, though, and playing with possible
solutions, I noted a couple of other pitfalls (which the current code
also appears to suffer from).
1. pthread_cond_wait() returning does not necessarily mean that the
cond var was signalled. Apparently
Hi Neil,
1. Embarassingly - given that I already said Nice fix to this - I'm
afraid I can't now see exactly why this is needed.
Argh, you're right -- when I first noticed this behavior, I was so
astonished to see my logs showing threads entering and leaving guile
mode during GC that my first
Hi Neil,
Would that also mean that you could revert the change to the spawning
of signal_delivery_thread()?
Of course.
As this stands, I'm concerned that
you're introducing an observable difference. For example: program
calls sigaction specifying a signal handler and a specific thread;
Hi Neil,
Thanks for your comments.
1. Some of your changes are bug fixes for the existing thread code,
and not dependent on SRFI-18, so we should apply these to 1.8.x as
well as to HEAD. Can you pull these out into a separate patch?
Sure.
2. I don't think it's clear what the
Hi Ludovic,
Due to several Important Events occurring in real life, I probably won't
have much time to take care of this by the end of January. If someone
else wants to take it over, that'd be great, otherwise we'll have to
wait some more. :-(
No worries -- I understand. I'm fine with
It's a bit of pain that srfi-18 doesn't refer forward to srfi-34/35.
Obviously the exception system of srfi-18 is very _like_ that of
srfi-34/35, but srfi-18 doesn't say whether its exceptions have to be
implemented using srfi-34/35.
I guess that doesn't actually matter, though. srfi-18
Yes, I'd prefer, if that's not too much work (but in this case you may
want to really use SRFI-34 and SRFI-35 rather than hand-write things
like (throw 'srfi-34 ...)).
Right, that's actually what I was trying to do, except that I've
discovered that SRFI-34 implements 'with-exception-handler'
Hi Ludovic,
I'm almost finished making the changes -- in fact, I've got everything
fixed except for this one:
I'd use pairs or records for exception objects rather than just symbols
since symbols can always be forged. So we'd have, e.g.:
(define uncaught-exception?
(let
Hi Ludovic,
Thanks so much for your comments! I'll try to address this stuff
tonight. Stress-testing on NetBSD sounds good!
Thanks,
Julian
On Nov 28, 2007 1:23 PM, Ludovic Courtès [EMAIL PROTECTED] wrote:
Hi Julian,
Overall, the patch looks good to me and your explanations were helpful.
any aspect of it!
Regards,
Julian
On Oct 29, 2007 9:37 AM, Julian Graham [EMAIL PROTECTED] wrote:
Hi Guilers,
Find attached a first draft of a patch to add SRFI-18 support to
Guile. The patch contains the necessary modifications to Guile's C
code to support SRFI-18, which is provided
Hi Guilers,
I was looking at some SRFIs recently (specifically SRFIs 88, 89, and
90), and I noticed that Guile could support all three of them pretty
easily if the reader allowed self-quoting keywords in which the colon
comes at the end, a la SRFI-88. The default reader behavior is to
only parse
From the recent experiments vs. Boehm GC, my impression was that
Guile's GC is already pretty good and that there is little scope for
improvement here.
Really? My (extremely unscientific) experiments were showing
something like 10ms for C-Guile calls that didn't involve GC, and
~100ms for
When I started using Guile, I was fully in sync with the embeddable
library approach, which means that I'd write, say, 75% of an
application in C, and then arrange to have the remainder written in
Scheme in an extensible fashion.
But I started really enjoying Scheme and wanting to write less
Find attached a patch that adds documentation for the thread
cancellation functions. Let me know if I should change anything.
On 10/23/07, Julian Graham [EMAIL PROTECTED] wrote:
Actually, condition variables and mutexes seem to be fairly well
documented, or did I miss something else
Hi Ludovic,
BTW, could you also provide a patch to update the documentation?
I'd be happy to -- I assume you're talking about stuff that's
currently missing, like documentation for the condition variable
functions?
___
Guile-devel mailing list
While testing some of the changes I made for SRFI-18 support, I
noticed a couple of deadlocks in my thread cancellation code. I've
updated my thread cancellation patch to address them. Specifically:
* If a thread was interrupted by a cancellation while it was in Guile
mode (i.e., holding its
Alright, so I've completed the parts of SRFI-18 that absolutely needed
to be written in C. I didn't modify the signatures of any existing
parts of the API, although I did add some new functions and change
behavior in a few places where I don't think it'll affect too many
people (and which I'll
Hi Ludovic,
Thus, you'd need to pinpoint what can be implemented without changing
the core API (e.g., do the SRFI-18 type predicates really require
changes in the core type predicates, or can they be implemented without
changing the core API?), what requires changes/additions in the core
Hi guys,
While I was waiting to get my copyright assignment sorted out, I
started trying to figure out what it would take to add SRFI-18
(http://srfi.schemers.org/srfi-18/srfi-18.html) support to Guile. I
think a lot of it can be safely done in Scheme (mostly by mapping the
SRFI's proposed API
On 9/26/07, Ludovic Courtès [EMAIL PROTECTED] wrote:
Anyway, as long as you have a reference to an object (including a thread
object), you can use the relevant procedures to mutate it. For
instance, if my code passes a list to yours, I have no guarantee that
your code won't call `set-car!'
I find it more elegant to use closures to that end. I.e., when
installing a handler, you'd write something like this:
(let ((cleanup (thread-cleanup-procedure (current-thread
(set-thread-cleanup-procedure! (current-thread)
(lambda ()
in formatting, etc., and I don't really know the vetting
procedure. I hope I've gotten the main bits right, though. Please let
me know if there are any changes I should make.
On 9/20/07, Julian Graham [EMAIL PROTECTED] wrote:
Would it be possible to defer execution of the Scheme code (cleanup
101 - 151 of 151 matches
Mail list logo
