Hi,
"Julian Graham" <[EMAIL PROTECTED]> writes:
> 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.
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
Hello,
"Neil Jerram" <[EMAIL PROTECTED]> writes:
> OK, that's in now. I had a few minor comments, please see the attached.
BTW, it'd be nice to have an "SRFI-18" node in the manual. :-)
Thanks,
Ludovic.
Hi Neil,
On Sat, May 24, 2008 at 7:42 AM, Neil Jerram <[EMAIL PROTECTED]> wrote:
>
> OK, that's in now. I had a few minor comments, please see the attached.
>
Hey, that's great! I know there are some unresolved issues -- I'll
address them as soon as I can. Thanks, again, to you and Ludovic fo
2008/5/24 Neil Jerram <[EMAIL PROTECTED]>:
> 2008/5/15 Julian Graham <[EMAIL PROTECTED]>:
>
>> Hi Neil,
>>
>> > I haven't covered these yet. Will try to soon, but could you resubmit
>> > anyway as a GIT commit patch, so that you end up being properly
>> > credited for the commit?
>>
>> Yes -- fin
2008/5/15 Julian Graham <[EMAIL PROTECTED]>:
> Hi Neil,
>
> > I haven't covered these yet. Will try to soon, but could you resubmit
> > anyway as a GIT commit patch, so that you end up being properly
> > credited for the commit?
>
> Yes -- find one attached.
OK, that's in now. I had a few mino
Hi Neil,
> I haven't covered these yet. Will try to soon, but could you resubmit
> anyway as a GIT commit patch, so that you end up being properly
> credited for the commit?
Yes -- find one attached. As an aside, I've been having some
difficulty with git, specifically when it comes to backing o
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Find attached a patch (in two parts [...]
Thanks; I've reviewed and applied those to my tree, and rebuilding
now; will push shortly unless I see any build errors.
> * Re-added support for locking mutexes with an owner other than the
> current thread
"Julian Graham" <[EMAIL PROTECTED]> writes:
> 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...)
Working on it this evening...
Neil
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 thread
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Were we to go this route (i.e., non-coexistence), I think the best
> solution would be something along the lines of the divide between
> Guile's built-in hash tables and SRFI-69 hash tables -- that is,
> obvious incompatibility based on data type. But
> > My understanding based on our previous
> > conversations is that we want core and SRFI-18 code to be able to
> > co-exist as much as possible...)
>
> I agree that we want co-existence in some sense, but I'm not sure that
> sense extends to mixing core and SRFI-18 API calls for the same
>
"Julian Graham" <[EMAIL PROTECTED]> writes:
>> 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 a
> 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
"Julian Graham" <[EMAIL PROTECTED]> writes:
> As regards the changes below, I've attached a patch against the new
> HEAD that I think resolves the issues you mentioned.
Thanks, that's in CVS now.
>> Finally, please note that we will need a NEWS entry for this work.
>> Are you happy to write th
"Julian Graham" <[EMAIL PROTECTED]> writes:
> 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-if
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 fir
Hi Neil,
> It looks great. I still have a few minor queries, but it's close
> enough now that I've committed this latest patch to CVS; it'll be much
> more convenient to work on the few remaining queries incrementally,
> rather than with respect to threads.c as it was prior to all these
> ch
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Find attached the latest revision of the core changes for SRFI-18
> support. Key changes between this revision and the last are:
>
> * scm_to_timespec -> to_timespec
> * "Timeout values" for timed joins
> * The extension of make-mutex and addition of
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:
* sc
"Julian Graham" <[EMAIL PROTECTED]> writes:
>> Agreed, that's a nice solution. The matter of whether a mutex can be
>> unlocked by another thread will depend on an application's design for
>> how it uses that mutex, and it feels right for the application to
>> declare this when the mutex is c
> Agreed, that's a nice solution. The matter of whether a mutex can be
> unlocked by another thread will depend on an application's design for
> how it uses that mutex, and it feels right for the application to
> declare this when the mutex is created, instead of on every unlock
> call.
>
>
"Julian Graham" <[EMAIL PROTECTED]> writes:
>> Sorry for missing this before. The SRFI-18 semantics are really
>> interesting, but I think we need to preserve the existing semantics
>> too for back-compatibility.
>
> Sure, fair enough.
>
>
>> I guess that means that scm_unlock_mutex_timed wil
Hi Neil,
> > No, we didn't, although I agree such a parameter would be pretty
> > useful.
>
> Well we discussed it a bit here:
> http://lists.gnu.org/archive/html/guile-devel/2008-02/msg4.html
> http://lists.gnu.org/archive/html/guile-devel/2008-02/msg5.html
Argh, don't know how I m
"Julian Graham" <[EMAIL PROTECTED]> writes:
>> > @c begin (texi-doc-string "guile" "join-thread")
>> > [EMAIL PROTECTED] {Scheme Procedure} join-thread thread
>> > [EMAIL PROTECTED] {Scheme Procedure} join-thread thread [timeout]
>> > @deffnx {C Function} scm_join_thread (thread)
>> > [EMAIL PRO
Hi Neil,
> Looking good! Many thanks for your continuing work on this, and sorry
> for my delay (once again!) in reviewing. I have a few comments, as
> follows.
No worries. Find my responses below.
> > @c begin (texi-doc-string "guile" "join-thread")
> > [EMAIL PROTECTED] {Scheme Procedure}
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Okay, find attached a patch against HEAD containing the aforementioned
> changes to the core for supporting SRFI-18. I'm still looping my test
> code, but I thought I should get something out to you guys this
> evening. In addition to the code change
>
> Works for me. I'll try to have something to you this weekend.
>
Okay, find attached a patch against HEAD containing the aforementioned
changes to the core for supporting SRFI-18. I'm still looping my test
code, but I thought I should get something out to you guys this
evening. In addition
> 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
>> * What should be the behavior of fat_mutex_lock when attempting to
>> lock an abandoned mutex -- in your earlier email, you seemed amenable
>> to the parts of SRFI-18 that shore up some of the poorly-defined
>> threading behavior in core threads. So should locking an abandoned
>> mutex be an er
> > 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 expo
"Julian Graham" <[EMAIL PROTECTED]> writes:
>> How about if the core join-thread takes an optional timeout-val
>> parameter, like SRFI-18 thread-join! ? If no timeout-val was
>> supplied, and the join timed out, the core join-thread would return
>> #f.
>
> For join-thread, sure. What about scm_j
I await your mutex wisdom; while I wait for tomorrow's post, though --
> How about if the core join-thread takes an optional timeout-val
> parameter, like SRFI-18 thread-join! ? If no timeout-val was
> supplied, and the join timed out, the core join-thread would return
> #f.
For join-thread, su
"Julian Graham" <[EMAIL PROTECTED]> writes:
>> > 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:
>
>
> Excell
> > 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 determini
"Julian Graham" <[EMAIL PROTECTED]> writes:
> 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) - tha
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
> mak
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Hi Neil,
Hello again! I've added some comments below, but I think that for the
last few emails we've rather lost sight of the ball - mostly my fault,
for pursuing details that didn't need pursuing. So actually my
comments below are not really import
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_thre
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Hi Neil,
Hi Julian; sorry for taking so long to follow up on this!
>> 2. If two threads are using pthread_cond_wait and pthread_cond_signal
>>to communicate, and using the cond_var itself as a state
>>indication, they have to be certain that
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
"Julian Graham" <[EMAIL PROTECTED]> writes:
> 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
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 firs
"Julian Graham" <[EMAIL PROTECTED]> writes:
> With regard to your comments about the rest of the patch, agreed, except:
>
> Given the similarities between the existing Guile threading code and
> SRFI-18, what level of comptability between these two domains will be
> supported? For example, SRFI-1
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Hi Neil,
>
>> > Of course.
>>
>> Good, thanks.
>
> Find attached a patch against HEAD that includes only the bug fix
> stuff (2 deadlocks and use of thread-specific admin mutex) from the
> original patch, modified to change make_jmpbuf instead of the s
Hi Neil,
> > Of course.
>
> Good, thanks.
Find attached a patch against HEAD that includes only the bug fix
stuff (2 deadlocks and use of thread-specific admin mutex) from the
original patch, modified to change make_jmpbuf instead of the signal
delivery code.
With regard to your comments about t
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Hi Neil,
>
>
>> Would that also mean that you could revert the change to the spawning
>> of signal_delivery_thread()?
>
> Of course.
Good, thanks.
>> As this stands, I'm concerned that
>> you're introducing an observable difference. For example: pro
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 thre
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Hi Neil,
>
> Thanks for your comments.
No problem. I feel like I'm being a bit awkward, so thanks for taking
these comments in good faith.
>> 1. Some of your changes are bug fixes for the existing thread code,
>>and not dependent on SRFI-18, so
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 ov
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Hi everyone,
>
> Thanks for your comments and patience. I've attached a new version of
> my SRFI-18 patch which I hope addresses the stuff that Ludovic raised.
I have some general comments. I'm sorry for not coming up with these
earlier.
1. Some of
"Julian Graham" <[EMAIL PROTECTED]> writes:
> 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 mor
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
Hi Julian,
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Thanks for your comments and patience. I've attached a new version of
> my SRFI-18 patch which I hope addresses the stuff that Ludovic raised.
> Sorry it's taken so long! In real life, I've been hung up on freeing
> myself from the entan
> 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-1
"Julian Graham" <[EMAIL PROTECTED]> writes:
> 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.
They can't be forg
"Julian Graham" <[EMAIL PROTECTED]> writes:
>> 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
> disc
Hi Julian,
"Julian Graham" <[EMAIL PROTECTED]> writes:
> The thing is, I can't throw with a key that's not a symbol. I've been
> trying to rig up something using SRFI-34-style exceptions (key =
> 'srfi-34, args = anything) -- provided I can make that work, would
> that be okay?
Yes, I'd prefer,
> 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-handle
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 ((excepti
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 helpf
Hi Julian,
Overall, the patch looks good to me and your explanations were helpful.
The caveat is that I'm not familiar with SRFI-18 and not too comfortable
with these parts of the pthread API that you're wrapping, so I may well
overlook a few things here and there. I think we'll have to stress-te
Hi Julian,
"Julian Graham" <[EMAIL PROTECTED]> writes:
> Just wanted to see if anyone had had a chance to take a look at the
> patch I attached to the last message on this thread.
Sorry, I've been busy over the last weeks, but it's really on my to-do
list for this week, trust me. :-)
Thanks,
L
Hi guys,
Just wanted to see if anyone had had a chance to take a look at the
patch I attached to the last message on this thread. Once again, I
know it's big for a patch (I'd be glad to break it into a few smaller
patches), but about half of it is Scheme code. I'd be happy to
explain / discuss a
Works like a charm! Thanks.
On 10/15/07, Stephen Compall <[EMAIL PROTECTED]> wrote:
> Julian Graham wrote:
> > (SRFI-18 make-condition-variable takes an optional argument that you
> > can use to "name" the condition var). To work around this, I was
> > going to create backup bindings of the ori
Julian Graham wrote:
(SRFI-18 make-condition-variable takes an optional argument that you
can use to "name" the condition var). To work around this, I was
going to create backup bindings of the original primitives and then
refer to them in my scheme reimplementations, a la:
(define guile:make-c
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 des
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 Julian,
"Julian Graham" <[EMAIL PROTECTED]> writes:
> All this kind of presumes that SRFI-18 is something that the Guile
> maintainers care about supporting. Is it? I'm afraid I don't know
> the Guile project's attitude towards implementing SRFIs.
I'm not sure there's an "official position"
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
72 matches
Mail list logo
