On 13/07/2010 05:49, Evan Laforge wrote:
On Mon, Jul 12, 2010 at 6:54 PM, John Meachamj...@repetae.net 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
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
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
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: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 as
So I was planning to pass a StorableVector to C. StorableVector uses
ForeignPtrs to manage its memory, so it should just be a pointer pass.
I happily wrote up a reference counting scheme so I could attach
decref to the finalizer and have haskell and C cooperate about when to
delete the pointer.
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
On Mon, Jul 12, 2010 at 12:54 PM, Edward Z. Yang ezy...@mit.edu 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
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
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 the
On Mon, Jul 12, 2010 at 1:53 PM, Edward Z. Yang ezy...@mit.edu 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
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)
On Mon, Jul 12, 2010 at 6:54 PM, John Meacham j...@repetae.net 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
13 matches
Mail list logo
