[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: srfi-18 requirements
Re: srfi-18 requirements
Thu, 07 Feb 2008 01:23:03 +0000
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
"Julian Graham" <address@hidden> 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:
> Excellent -- I'll let you know if I can think of a deterministic way
> to reproduce that from user code.
Thanks. I've decided to give up on this for now, and just check in
I was playing with code like the attached patch - which I think is
already more effort than it's worth spending to be able to regressibly
test this :-) - and then I found that even this doesn't work reliably.
To be precise, it hangs every time when run under GDB, but not when
run outside GDB.
So I think the wise course is to accept that there are some things we
can't write tests for.
Description: Text Data
> At any rate, let me pop a few frames off the stack. The two remaining
> changes for the core features patch were providing a join_thread that
> could indicate a timeout without throwing an SRFI-18 exception; and
> providing a well-defined fat_mutex_lock that doesn't rely on the
> SRFI-18 notion of mutex state. Two questions:
> * What would be an appropriate way for join_thread to indicate a
> timeout? Given that it's a primitive that can be called from Guile, I
> take it that the standard C approach of passing a pointer to a flag is
> out of the question. Would it be good enough to have it return #f on
> timeout (even if that leaves some amiguity about whether there was a
> timeout or just a lack of a thread return value)? Is there a core
> exception it could throw?
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
The #f would indeed be ambiguous, but any given caller can eliminate
the ambiguity if they choose to by specifying a timeout-val.
Note that thread-join! can map onto this, in the case where _it_ gets
no timeout-val, by constructing a unique object such as (list
'timeout) and passing this as the timeout-val to the core join-thread.
> * 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 error? If so, what kind? Or should locking an abandoned
> mutex not be an error at all unless you do it using the SRFI-18 API?
I'll get back to you on this one tomorrow!
- Re: srfi-18 requirements, Neil Jerram, 2008/02/02
- Re: srfi-18 requirements, Julian Graham, 2008/02/05
- Re: srfi-18 requirements,
Neil Jerram <=
- Re: srfi-18 requirements, Neil Jerram, 2008/02/07
- Re: srfi-18 requirements, Julian Graham, 2008/02/07
- Re: srfi-18 requirements, Julian Graham, 2008/02/11
- Re: srfi-18 requirements, Neil Jerram, 2008/02/19
- Re: srfi-18 requirements, Julian Graham, 2008/02/19
- Re: srfi-18 requirements, Neil Jerram, 2008/02/21
- Re: srfi-18 requirements, Julian Graham, 2008/02/21