Oh, right --- I was confusing 'interior with 'atomic-interior... and so does the implementation! The `malloc` implementation uses the 'atomic-interior allocator for 'interior.
That's easy to fix, and I'll push a repair. Meanwhile, I guess the answer is to avoid 'interior. At Tue, 1 Jan 2019 10:10:33 -0800 (PST), Ronald Garcia wrote: > Hi Matthew, > > Thanks for the reply. However, I see I mis-wrote: I meant to say that > 'interior is supposed to be like 'non-atomic, (whereas 'atomic-interior is > like 'atomic). > Does that not make a difference? > > Thanks! > Ron > > > On Tuesday, January 1, 2019 at 10:06:56 AM UTC-8, Matthew Flatt wrote: > > > > Hi Ron, > > > > You can't install a Racket value into memory allocated with 'atomic or > > 'interior. (That is, 'interior is like 'atomic, just as you write, and > > not like 'nonatomic.) > > > > If you need a value that doesn't move and can reference a Racket value, > > try `malloc-immobile-cell`. > > > > Matthew > > > > At Tue, 1 Jan 2019 10:00:42 -0800 (PST), Ronald Garcia wrote: > > > Hello, > > > > > > I'm trying to better understand how ffi/unsafe works, and I've run into > > > something I'm failing to understand. Consider the following code: > > > > > > #lang racket > > > (require ffi/unsafe) > > > > > > ;; > > > ;; cbox-struct.rkt > > > ;; > > > > > > (define-struct data (a b)) > > > > > > (define (cbox s) > > > (define ptr (malloc _racket 'interior)) > > > (ptr-set! ptr _racket s) > > > ptr) > > > > > > (define (cunbox cb) > > > (ptr-ref cb _racket 0)) > > > > > > (define cb1 (cbox (make-data 1 2))) > > > > > > (collect-garbage 'major) > > > > > > (data-a (cunbox cb1)) > > > > > > > > > If I run this in Dr. Racket 7.1, I get the following error: > > > data-a: contract violation; > > > given value instantiates a different structure type with the same name > > > expected: data? > > > given: #<data> > > > > > > - If I replace 'interior with 'nonatomic, the program successfully > > produces > > > 1. > > > This difference in behaviour surprises me, since the docs for malloc > > seem > > > to suggest > > > (by appeal to the "scheme_malloc" C functions) that interior and atomic > > > only differ in > > > whether interior pointers are allowed and whether the object is ever > > moved. > > > > > > Any ideas about what's happening here? > > > > > > Thanks! > > > Ron > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
