| > I remember this discussion of a
| > so-called "special rule" for ForeignObjs from previously, and I still
| > don't understand why it is "special" rather than the obvious and only
| > way to do things.
|
| In case of a tail call to a C routine, ghc could
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
[..]
> The drawback of marsh* is that calls are not uniform. Sometimes
> marsh* are not needed, sometimes they are not sufficient (with array
> and its length passed as separate arguments), initial arguments are
> simpler to pass by partial app
Malcolm Wallace <[EMAIL PROTECTED]> wrote,
> Sven says:
>
> > I'd like to finish discussion around the low-level aspects of the
> > FFI, so I propose the following: If none of the implementors yells
> > loudly that the ForeignObj FFI rule is costly to implement, this
> > lifetime rule should be
o implement, this
> lifetime rule should be left as it is. (It can't be hard to implement,
> because as a fallback the StablePtr "trick" could be used.) We all
> agree that it is easy and safe to use, and captures a common case.
> But we still need foreignObjToAddr
[EMAIL PROTECTED] writes:
>
> Sven says:
>
> > I'd like to finish discussion around the low-level aspects of the
> > FFI, so I propose the following: If none of the implementors yells
> > loudly that the ForeignObj FFI rule is costly to implement, this
> > lifetime rule should be left as it is.
> Sven says:
>
> > I'd like to finish discussion around the low-level aspects of the
> > FFI, so I propose the following: If none of the implementors yells
> > loudly that the ForeignObj FFI rule is costly to implement, this
> > lifetime rule should be left as it is. (It can't be hard to
> imple
Sven says:
> I'd like to finish discussion around the low-level aspects of the
> FFI, so I propose the following: If none of the implementors yells
> loudly that the ForeignObj FFI rule is costly to implement, this
> lifetime rule should be left as it is. (It can't be hard to implement,
> because
costly to implement, this
lifetime rule should be left as it is. (It can't be hard to implement,
because as a fallback the StablePtr "trick" could be used.) We all
agree that it is easy and safe to use, and captures a common case.
But we still need foreignObjToAddr for marshaling co
Mon, 21 Feb 2000 11:57:18 +0100, Sven Panne <[EMAIL PROTECTED]>
pisze:
> Granted, but nevertheless I support Manuel's view: The FFI should
> deal with *primitive* types automatically and libraries/tools should
> take care of the rest.
In principle I agree, but here IMHO manual protection would
Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes:
>
...
> > >
> > > As SimonM said in a previous email (and Michael Weber
> > > pointed out in our earlier discussion), if you pass a
> > > ForeignObj to C and want to be sure that it doesn't get
> > > finalised, you have to StablePtr it. Why
tremely rare circumstances some can) could trigger the
> finalizer, which I'm not sure is always harmless in my case... Can it?
It can't: the rule is that the ForeignObj stays live at least until the
foreign call returns.
> Then it's bad. Otherwise IMHO they are safe and conve
> Much of the "overhead" of StablePtrs at the moment is due to
> the hash table and reference count business that is
> implicitly performed by the stable pointer routines. So
> far, I haven't seen a good explanation as to why this is
> actually needed. If we would get rid of it, StablePtrs
> wo
Marcin 'Qrczak' Kowalczyk wrote:
> On the one hand, I certainly would not be happy to add to all
> those 50 foreign imports that use ForeignObjs code dealing with
> protecting them.
Granted, but nevertheless I support Manuel's view: The FFI should
deal with *primitive* types automatically and lib
harmless in my case... Can it?
Then it's bad. Otherwise IMHO they are safe and convenient enough, the
unsafety if other cases is recognized by using foreignObjToAddr.
I seek for a safe, simple and cheap way of protecting ForeignObjs
across C calls, rarely across a bit more than a C call
Sigbjorn Finne <[EMAIL PROTECTED]> wrote,
> Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes:
> >
>
> > > Passing foreign objects directly via the FFI does not have this
> > > problem, because there is a special lifetime guarantee for this
> > > kind of values. :-P
> >
> > Actually, do
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> I use C2HS libraries now (but the c2hs program needs so *MUCH*
> memory and time to parse Perl headers that I can't use it here;
> fortunately there is no need to marsh C structures).
The last version of C->HS on the Web page has a *big* sp
Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes:
>
> >
> > Passing foreign objects directly via the FFI does not have this
> > problem, because there is a special lifetime guarantee for this
> > kind of values. :-P
>
> Actually, doesn't that prove the point that I tried to make
> whe
ime ago) is exemplified by the following code snippet:
>
>addr <- foreignObjToAddr fo -- last reference of `fo'
>-- Murphy's Law strikes again: GC is happening exactly here
>res <- someExternalFunction addr -- dangling reference :-(
>
> Passing foreig
Thu, 17 Feb 2000 12:04:52 +0100, Sven Panne <[EMAIL PROTECTED]>
pisze:
> Not exactly. The real problem (pointed out to me by Manuel Chakravarty
> some time ago) is exemplified by the following code snippet:
[...]
I had exactly that thing in mind.
Thu, 17 Feb 2000 14:21:12 +0100, Sven Panne <[E
Marcin 'Qrczak' Kowalczyk wrote:
> The function is described as unsafe because the result loses the
> finalizer, right? [...]
Not exactly. The real problem (pointed out to me by Manuel Chakravarty
some time ago) is exemplified by the following code snippet:
addr <-
> The function is described as unsafe because the result loses the
> finalizer, right?
>
> So it is in fact unsafe to store a list of such Addrs in malloced
> memory, passing the pointer to the array to a C function, because
> they can be garbage collected and finalized during storing them,
> bef
The function is described as unsafe because the result loses the
finalizer, right?
So it is in fact unsafe to store a list of such Addrs in malloced
memory, passing the pointer to the array to a C function, because
they can be garbage collected and finalized during storing them,
before the C func
22 matches
Mail list logo
