headers
Ivan Shmakov | 2 Apr 2006 19:38
Picon

why no FLUID? predicate?

	It looks somewhat odd to have the fluid data type without the
	corresponding FLUID? predicate.  Is there any reason for such
	inconsistency?  Unless there is one, I suggest the following
	change:

--- scheme48-1.3/scheme/interfaces.scm~	2005-04-27 15:46:00.000000000 +0700
+++ scheme48-1.3/scheme/interfaces.scm	2006-04-02 23:45:23.476357000 +0700
 <at>  <at>  -444,6 +444,7  <at>  <at> 

 (define-interface fluids-interface
   (export make-fluid
+	  fluid?
 	  let-fluid
 	  let-fluids
 	  fluid
--- scheme48-1.3/scheme/rts/fluid.scm~	2005-04-27 15:46:01.000000000 +0700
+++ scheme48-1.3/scheme/rts/fluid.scm	2006-04-02 23:50:03.920386000 +0700
 <at>  <at>  -68,6 +68,7  <at>  <at> 

 (define-record-type fluid :fluid
   (make-fluid top)
+  fluid?
   (top fluid-top-level-value set-fluid-top-level-value!))

 (define (fluid f)
Permalink | Reply | 0 comments |
headers
Heath Putnam | 5 Apr 2006 18:23

Minor runtime feature


I've attached a tiny patch to make it possible for the user to handle
deadlocks in scheme48's runtime as CML events:

diff /tmp/scheme48-1.3/scheme/rts/root-scheduler.scm /usr/local/src/scheme48-1.3/scheme/rts/root-scheduler.scm
149,152d148
< (define (current-deadlock-handler)
<   (session-data-ref deadlock-handler))
<   
< 
diff /tmp/scheme48-1.3/scheme/rts-packages.scm /usr/local/src/scheme48-1.3/scheme/rts-packages.scm
326,327c326
< 					 call-when-deadlocked!
< 					 current-deadlock-handler)
---
> 					 call-when-deadlocked!)

I'm not sure if that should be merged in to the main tree; I certainly
seem to need something like this. You have to rebuild the image, as it
changes the runtime system.

Nothing further in this message is critical (but the crash of the VM
is interesting) , unless you are interested in Scheme48's runtime or
uses of CML. If you have any tips for me, I'd appreciate it. 

If the user can override what happens when things deadlock, it is
possible to use scheme48 to make certain kinds of simulators easily,
as long as you can live with certain constraints. The basic idea is to
build a system that advances the simulation time when the system has
acquiesced (deadlocked).
(Continue reading)

Permalink | Reply | 501 comments |
headers
Taylor R. Campbell | 6 Apr 2006 03:19
Favicon

LOAD-DYNAMIC-EXTERNALS bug

The procedure LOAD-DYNAMIC-EXTERNALS passes the wrong number of
arguments to RELOAD-DYNAMIC-EXTERNALS-INTERNAL if it is reloading the
library.  It omits the argument specifying whether or not to close the
old shared object first.
Permalink | Reply | 1 comment |
headers
Heath Putnam | 9 Apr 2006 18:49

Fix for broken CML sync routines


There is a bug in the CML library's synchronization routines.  The
library uses with-new-proposal in a bad way: the wrap-proc of the
synchronized event gets called with a different continuation than the
sync. The continuation only resets the propsal and calls the original
continuation.

The result is that the following typical CML programs (below) can
exahust the heap, as it fills up with continuations that reset a
proposal. The original code didn't do this - it was careful to exit
the critical region before calling the wrap proc:

original code, ala Reppy:
...
((enabled? status)
 (let ((value ((enabled-do-thunk status))))
   (leave-cr!)         ;; << Do this first
   (wrap-proc value))) ;; << then the tail-call
((blocked? status)
 (let ((trans-id (make-trans-id)))
   ((blocked-proc status) trans-id values wrap-proc)
   (let ((pair (cr-trans-id-wait trans-id))) ;; << do this first
     ((cdr pair) (car pair))))) ;; then the tail call

The fix is just to make this adjustment:

FROM
(with-new-proposal (lose)
        ... (wrap-proc value) ...)
TO
(Continue reading)

Permalink | Reply | 1 comment |
headers
Taylor R. Campbell | 9 Apr 2006 21:53
Favicon

Re: Fix for broken CML sync routines

As you may remember, I have my own CML library, which I originally
wrote only to understand the workings of CML better.  Since I
originally wrote it in Scheme48 using interrupt disablement for
critical regions, though, I've generalized and abstracted the critical
region and thread suspension/revival mechanism.  (This kind of
abstraction is what I suspect Mike was referring to at the top of
rendezvous.scm in Scheme48 1.3's CML library.)

There are seven procedures, now, for using critical regions and
suspending & reviving threads.  Not only does this interface support
both optimistic concurrency and interrupt disablement, but it was
general enough that I was able to port it to MIT Scheme with minimal
effort.  And although my code was bitten by the same bug Heath pointed
out, it was very easily fixable, simply by changing the details of the
Scheme48 implementation of the well-defined critical region & thread
suspension/revival interface; it was not necessary to grovel through
and modify a great deal of the rendezvous machinery.

For those curious, my library is available at

  <http://mumble.net/~campbell/darcs/scm-rendezvous/>;

unfortunately, it's not quite as well-tested as Scheme48 1.3's CML
library, so it is more likely to have bugs lurking in it, but I'm very
happy with the abstraction of critical regions and thread suspension &
revival.
Permalink | Reply | 0 comments |
headers
Michael Sperber | 12 Apr 2006 19:40
Picon

Re: LOAD-DYNAMIC-EXTERNALS bug


"Taylor R. Campbell" <campbell <at> mumble.net> writes:

> The procedure LOAD-DYNAMIC-EXTERNALS passes the wrong number of
> arguments to RELOAD-DYNAMIC-EXTERNALS-INTERNAL if it is reloading the
> library.  It omits the argument specifying whether or not to close the
> old shared object first.

Thanks for the report!  This will be fixed in the next release.

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Permalink | Reply | 0 comments |
headers
Eric Merritt | 29 Apr 2006 01:40
Picon
Gravatar

A small bug in prescheme

It seems I have discovered a small bug in prescheme. It could be that
I am mistaken, but I thought I would post it to the list in any case.
I am using the latest stable version of scheme48 and I get the same
output on both mac-osx and ubuntu Linux (as you would expect). As you
can see in 'free-test' and 'free-test-wrong' one of the deallocations
goes missing if the '#t' isn't returned. It seems the presence of the
return value causes correct output and it's absence causes problems.
Using a return value works just fine for me so this doesn't cause me
any problems, but its worth noting.

-- test-packages.scm:
;;; -*- mode: scheme; scheme48-package: application -*-

(define-structure test
  (export free-test free-test-wrong)
  (open prescheme ps-record-types)
  (files test))

-- test.scm:
;;; -*- mode: scheme; scheme48-package: application -*-
(define-record-type test :test
  (really-make-test body)
  (body (^ integer) test-body))

;; Produces correct code
(define (free-test q)
  (deallocate (test-body q))
  (deallocate q)
  #t)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane