Excerpts from Axel Simon's message of Tue Jul 13 16:28:29 -0400 2010:
> Well, if the C code hangs on to the StablePtr that wraps the
> ForeignPtr, its finalizer won't be run. But can run again once the
> StablePtr is freed. So you can take out the Ptr in the ForeignPtr and
> use it in C land
On Jul 13, 2010, at 22:17, Edward Z. Yang wrote:
Excerpts from Axel Simon's message of Tue Jul 13 16:03:01 -0400 2010:
If your C code has a way to properly unref a pointer then you could
wrap your ForeignPtr in a StablePtr and pass that to C land. Once C
has freed the StablePtr the ForeignPtr
Excerpts from Axel Simon's message of Tue Jul 13 16:03:01 -0400 2010:
> If your C code has a way to properly unref a pointer then you could
> wrap your ForeignPtr in a StablePtr and pass that to C land. Once C
> has freed the StablePtr the ForeignPtr can become dead when Haskell
> has dropped
Hi Evan, Ed,
On Jul 12, 2010, at 22:53, Edward Z. Yang wrote:
Excerpts from Evan Laforge's message of Mon Jul 12 16:43:45 -0400
2010:
Yeah, that's definitely the safest and simplest. But the copying
defeats the purpose of passing a pointer in the first place, which
was
to not have to copy
On 13/07/2010 05:49, Evan Laforge wrote:
On Mon, Jul 12, 2010 at 6:54 PM, John Meacham wrote:
Hi, is a StablePtr what you are after?
Indeed, it looks like StablePtr will get me what I want. It's a
little less convenient than FunPtr because I'm already doing some
finalization of FunPtrs and I
On Mon, Jul 12, 2010 at 6:54 PM, John Meacham wrote:
> Hi, is a StablePtr what you are after?
Indeed, it looks like StablePtr will get me what I want. It's a
little less convenient than FunPtr because I'm already doing some
finalization of FunPtrs and I can reuse the same callback, but it
looks
Hi, is a StablePtr what you are after?
http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Foreign-StablePtr.html
you can pass a stableptr to the foreignptr to C and it won't be freed
until you explicitly get rid of the stableptr (and all haskell
references are gone)
John
On Mon, Jul 12, 2010 at 1:53 PM, Edward Z. Yang wrote:
> Excerpts from Evan Laforge's message of Mon Jul 12 16:43:45 -0400 2010:
>> Yeah, that's definitely the safest and simplest. But the copying
>> defeats the purpose of passing a pointer in the first place, which was
>> to not have to copy the
On Mon, Jul 12, 2010 at 5:23 PM, Evan Laforge wrote:
> Another hack I thought of:
>
> - store ptr in a global MVar in haskell, pass it to C
> - C does its thing, ptr stays alive because haskell still has a reference
> - now when C calls the finalize funptr, it deletes the ptr from the
> haskell MV
Excerpts from Evan Laforge's message of Mon Jul 12 16:43:45 -0400 2010:
> Yeah, that's definitely the safest and simplest. But the copying
> defeats the purpose of passing a pointer in the first place, which was
> to not have to copy the giant array just to pass it.
Well, if your C code wasn't sq
> The easiest thing to do is copy the contents to a regular area of memory not
> managed by a Storable Vector. This'll be much less painful because it's just
> a
> normal free (not a recursive one, which can get hairy).
Yeah, that's definitely the safest and simplest. But the copying
defeats th
Excerpts from Evan Laforge's message of Mon Jul 12 16:23:39 -0400 2010:
> Well, what I'm worried about is that withForeignPtr says you should
> only use the pointer from inside it. The situation here is that I've
> passed a pointer to C. C wants to share ownership of the pointer, so
> even if all
On Mon, Jul 12, 2010 at 12:54 PM, Edward Z. Yang wrote:
> Excerpts from Evan Laforge's message of Mon Jul 12 14:56:11 -0400 2010:
>> But I'm not convinced that's actually enough because the C code is
>> still running outside of a withForeignPtr. I would have to do
>> something really hairy like c
Excerpts from Evan Laforge's message of Mon Jul 12 14:56:11 -0400 2010:
> But I'm not convinced that's actually enough because the C code is
> still running outside of a withForeignPtr. I would have to do
> something really hairy like call back to C from the haskell callback,
> wrapping it in with
14 matches
Mail list logo
