Ken Raeburn <[EMAIL PROTECTED]> writes:
> Of course, the compiler might reorder these accesses, unless you
> make everything volatile. Even then, the CPU still might reorder
> them so another compiler might see something different. I'd be
> worried about the reordering or caching in another proc
On Dec 7, 2005, at 17:47, Rob Browning wrote:
{
SCM ans = scm_call_0(SCM_PROMISE_DATA (ans));
SCM_SET_PROMISE_DATA(p, ans);
SCM_SET_PROMISE_MUTEX(p, SCM_BOOL_F) // (do last to avoid
race at [1])
result = SCM_PROMISE_DATA(p);
}
Of course, the compiler might reo
Kevin Ryde <[EMAIL PROTECTED]> writes:
> An even more radical idea would be not to have a mutex at all. If
> two threads are simultaneously forcing then whichever finishes first
> sets the forced value. (The same way that recursive forcing results
> in the first finisher setting the value.)
Thi
Rob Browning <[EMAIL PROTECTED]> writes:
>
> Note that this wouldn't be safe if the initial mutex assignment might
> copy a value that has been half filled by some other thread.
Yep, a single fetch is assumed to be ok in other places too.
An even more radical idea would be not to have a mutex at
Kevin Ryde <[EMAIL PROTECTED]> writes:
> (Speaking of which, I'd thought before that once a promise is forced
> it shouldn't need a mutex any more, which would save a bit of time and
> space.)
I suppse it might, though you'd have to be very careful with the
coding. i.e. (offhand) you would proba
Rob Browning <[EMAIL PROTECTED]> writes:
>
> Does anyone know what the arguments are, if any, for implementing
> delay and force directly in eval.c rather than more generically, at
> the Scheme level, perhaps in boot-9.scm via define-record, lambda,
> etc.?
I imagine some C code is less bytes for
On Dec 6, 2005, at 14:10, Marius Vollmer wrote:
Ken Raeburn <[EMAIL PROTECTED]> writes:
Somebody please check me on this, I'm not sure if scm_leave_guile can
be relied upon to work.
I believe everything you say is correct, unfortunately.
Sorry. :-)
I was hoping maybe I was missing something.
I'm seeing a failure of the test-system-cmds test, and have narrowed
it down to this:
[EMAIL PROTECTED]:~/guile-cvs-head/guile/guile-core$ ./pre-inst-guile -q
guile> (exit 42)
Segmentation fault
Neil
___
Guile-devel mailing list
Guile-devel@gnu
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>
>> (oop goops util) is not meant to be used outside the goops
>> implementation. I'd rather not touch it for cosmetic purposes
>> only... :-)
>
> Sure, but why re-implement a subset of SRFI-1 in there, espe
Marius Vollmer <[EMAIL PROTECTED]> writes:
> C code can observe the GC doing its thing (via the smob free
> functions). In order not to overconstrain the implementation of the
> GC (which is pretty constrained already anyway), we have the
> additional rule that there is no guarantee about the ord
Marius Vollmer <[EMAIL PROTECTED]> writes:
> These two 'raise' funtions are very different: one raises a Unix
> signal, the other raises an exception. So I'd say the warning is OK.
[...]
> The same is true for 'bit-count' as Kevin pointed out.
I agree that these are way different functions, b
Marius Vollmer <[EMAIL PROTECTED]> writes:
> (oop goops util) is not meant to be used outside the goops
> implementation. I'd rather not touch it for cosmetic purposes
> only... :-)
Sure, but why re-implement a subset of SRFI-1 in there, especially
non-tail-recursive variants?
Thanks,
Ludovic.
Hi,
Marius Vollmer <[EMAIL PROTECTED]> writes:
> I made the following changes. OK?
Looks perfect to me!
But what about the rest of the patch, namely:
> 2005-11-07 Ludovic Courtès <[EMAIL PROTECTED]>
>
> * srfi-19.scm (current-time): Replace it instead of exporting
> it.
>
>
13 matches
Mail list logo
