[REBOL] Re: callbacks
From: lmecir:mbox:vol:cz at: 7-Nov-2007 6:16
Hi Max,
> I allocate nothing, its a callback. the lib calls my func. I never build a
> struct except to supply the callbacks upon loading the lib, and that is
> safe.
Sorry for not believing you, it looked so improbable, but you were
right! Rebol indeed recycled the memory it did not allocate.
> Maybe its possible the gc could recycle in the window of time in between
> change pointer address and doing the copy, but if this is the case, both
> versions I guess suffer the same fatality. maybe adding a recycle/off
> recycle/on pair within the func could prevent this possibility.
>
There indeed is a problem with your memcopy version. The code below
reliably
crashes the console, when copied and pasted to it:
include %peekpoke.r
include %timblk.r
a: #{00010203040506070809}
aa: string-address? a
time-block [memcopy-max aa 10] 0,05
time-block [memcopy-max aa 10] 0,05
After inserting recycle/off; recycle/on pair as follows:
memcopy-max: func [
{copies a region of ram given at address with sizeof length.}
address [integer!]
length [integer!]
/local struct-struct buffer addr
] [
recycle/off
address: make struct! [address [integer!]] reduce [address]
struct-struct: make struct! compose/deep [
struct [struct! [(head insert/dup copy [] [c [char]] length)]]
] none
addr: copy third struct-struct
change third struct-struct third address
buffer: copy third struct-struct/struct address
change third struct-struct third addr
recycle/on
buffer
]
the crash was still there.
> previously, anytime the GC would pick up the struct it would crash. Delay
> was no issue, the stuct really is left corrupted, my guess is that the GC
> attempts a free() on the memory pointed to by address. There are a few
> reasons why structs could actually be allocated manually, outside of the
> normal recycling pool, and since there is a GC managing the struct rebol
> wrapper anyways, the rule that everything eventually gets freed is still
> applicable.
>
> wrt speed, my tests where within my whole environment. I'm sorry if a pure
> test shows you're function almost twice as fast, and I insinuated otherwise.
+187% in speed means 287% in total ;-)
> just a question, can you add a to-binary to your memcopy and see the speed
> impact that has?
to-binary is not necessary, as-binary suffices and it is faster. The
speed difference between a version returning string and a version using
as-binary to return a binary is almost unmeasurable. Here it is:
memcopy: func [
{copy a region of memory given at address with the given size}
address [integer!]
size [integer!]
/local s c
] [
address: make struct! [address [integer!]] reduce [address]
s: make struct! compose/deep [c [char-array (size)]] none
change third s third address
c: s/c
change third s #{00000000}
as-binary c
]
-L
