Re: [Caml-list] camlidl and pointer to function

Re: [Caml-list] camlidl and pointer to function

[Marcin 'Qrczak' Kowalczyk]

Wed, 14 Nov 2001 15:43:16 -0500, Krishnaswami, Neel <neelk@cswcasa.com> pisze:

> Is this it?
> 
> http://users.n.ml.org/nc/ffcall/callback.html

Yes.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] camlidl and pointer to function

[Dmitry Bely]

"Krishnaswami, Neel" <neelk@cswcasa.com> writes:

> > > I've once seen a C library which tries to provide it for several
> > > platforms but I forgot its name.
> > 
> > It would be nice if you recall it :-)
> 
> Is this it?
> 
> http://users.n.ml.org/nc/ffcall/callback.html

But where is the library itself? That's just the very short description ...

Hope to hear from you soon,
Dmitry


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

RE: [Caml-list] camlidl and pointer to function

[Krishnaswami, Neel]

Dmitry Bely [mailto:dbely@mail.ru] wrote:
> > 
> > I've once seen a C library which tries to provide it for several
> > platforms but I forgot its name.
> 
> It would be nice if you recall it :-)

Is this it?

http://users.n.ml.org/nc/ffcall/callback.html

--
Neel Krishnaswami
neelk@cswcasa.com
 
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] camlidl and pointer to function

[Dmitry Bely]

Dmitry Bely <dbely@mail.ru> writes:

> "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> writes:
> 
> > > The problem is that C library is binary-only (Intel image processing
> > > library), and CallBack type is exactly 
> > > 
> > > typedef int (*CallBack)(int);
> > 
> > Converting a function closure to a C function pointer can't be done
> > portably, but it can be done with lots of ugly magic.
> > 
> > Glasgow Haskell does this (by generating a piece of assembler on
> > the heap) and it's convenient to use from the level of Haskell.
> > Such functions need to be explicitly freed of course.
> > 
> > GNU C does this for local functions, but only "downwards". If the
> > function pointer doesn't need to live longer than the function which
> > installs the callback, the GNU C extension can be used. It generates
> > the piece of assembler on the stack. To use it - just define a function
> > inside a function and take its address.
> 
> Hmm, this trick assumes that the stack is executable (IMHO, the serious
> security hole). Don't know about Linux/x86 page/segment attributes policy,
> but I am almost sure that Windows NT/2000 x86 (which is my platform) will
> not allow to execute the code in data/stack pages.

Sorry, in fact i386 and above does not seems to have page-level execute
permissions, so this trick will work on all i386 flat model-based OSes
(I've tried it under Win2000). Now I would like to see this implemented in
camlidl :-)

Here is the way I am going to use right now:

[---cut---]
typedef [abstract] void* SomeType;

// typedef RES (CALLBACK*)(PARAM);
typedef [abstract] void* CALLBACK; 
typedef int RES;
typedef int PARM;

void convert( SomeType* in, SomeType* out, CALLBACK cb)
  quote(call,"\
  {                                                  \n\
    value v = *(value*)cb;                           \n\
    RES _cb(PARM p)                                  \n\
    {                                                \n\
      value _v_p;                                    \n\
      RES _res;                                      \n\
      value _vres;                                   \n\
                                                     \n\
      _v_p = camlidl_c2ml_cback_PARM(&p,_ctx);       \n\
      _vres = callback(v,p);                         \n\
      camlidl_ml2c_cback_RES(_vres,&_res,_ctx);      \n\
      return _res;                                   \n\
    }                                                \n\
    convert(in,out,_cb);                             \n\
  }                                                  \n\
  ");
[---cut---]

Unfortinately, I cannot define such macro for camlidl, as it does not allow
C-style string concatenation inside quote statement...

> > It would be nice if OCaml provided this functionality because not
> > all C libraries provide the extra argument for simulating closures.
> > Unfortunately it can't be implemented nicely.
> > 
> > I've once seen a C library which tries to provide it for several
> > platforms but I forgot its name.
> 
> It would be nice if you recall it :-)

Hope to hear from you soon,
Dmitry


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] camlidl and pointer to function

[Dmitry Bely]

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> writes:

> > The problem is that C library is binary-only (Intel image processing
> > library), and CallBack type is exactly 
> > 
> > typedef int (*CallBack)(int);
> 
> Converting a function closure to a C function pointer can't be done
> portably, but it can be done with lots of ugly magic.
> 
> Glasgow Haskell does this (by generating a piece of assembler on
> the heap) and it's convenient to use from the level of Haskell.
> Such functions need to be explicitly freed of course.
> 
> GNU C does this for local functions, but only "downwards". If the
> function pointer doesn't need to live longer than the function which
> installs the callback, the GNU C extension can be used. It generates
> the piece of assembler on the stack. To use it - just define a function
> inside a function and take its address.

Hmm, this trick assumes that the stack is executable (IMHO, the serious
security hole). Don't know about Linux/x86 page/segment attributes policy,
but I am almost sure that Windows NT/2000 x86 (which is my platform) will
not allow to execute the code in data/stack pages.

> It would be nice if OCaml provided this functionality because not
> all C libraries provide the extra argument for simulating closures.
> Unfortunately it can't be implemented nicely.
> 
> I've once seen a C library which tries to provide it for several
> platforms but I forgot its name.

It would be nice if you recall it :-)

Hope to hear from you soon,
Dmitry


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] camlidl and pointer to function

[Marcin 'Qrczak' Kowalczyk]

14 Nov 2001 15:16:15 +0300, Dmitry Bely <dbely@mail.ru> pisze:

> The problem is that C library is binary-only (Intel image processing
> library), and CallBack type is exactly 
> 
> typedef int (*CallBack)(int);

Converting a function closure to a C function pointer can't be done
portably, but it can be done with lots of ugly magic.

Glasgow Haskell does this (by generating a piece of assembler on
the heap) and it's convenient to use from the level of Haskell.
Such functions need to be explicitly freed of course.

GNU C does this for local functions, but only "downwards". If the
function pointer doesn't need to live longer than the function which
installs the callback, the GNU C extension can be used. It generates
the piece of assembler on the stack. To use it - just define a function
inside a function and take its address.

It would be nice if OCaml provided this functionality because not
all C libraries provide the extra argument for simulating closures.
Unfortunately it can't be implemented nicely.

I've once seen a C library which tries to provide it for several
platforms but I forgot its name.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] camlidl and pointer to function

[Dmitry Bely]

"NASSOR Eric" <nassor@crf.canon.fr> writes:

> > I have a C library function with interface like following:
> >
> > typedef [abstract] void* SomeType;
> > typedef int (*CallBack)(int);
> > void convert( SomeType* in, SomeType* out, CallBack c);
> >
> > It would be nice to use it in caml the following way:
> >
> > external convert: someType->someType->(int->int)->unit = "something"
> > ...
> > convert stIn stOut ((+) 1)
> > ...
> >
> > Unfortinately CamIDL language does not allow the pointer to function as a
> > valid type, but maybe there is some common solution/workaround for this
> > problem? Or the only way is writing necessary stubs and conversion
> > functions by hands? Is is possible at all?
> >
> 
> It is possible to call back caml code from a C code which was called from caml, but
> you need to write a few lines of code.
> here is an example extracted from my application (with a few simplifications).
> the resulting caml function iter_tree can be called recursively, it can also raise
> exceptions.

The problem is that C library is binary-only (Intel image processing
library), and CallBack type is exactly 

typedef int (*CallBack)(int);

I cannot add value parameter containing Caml callback here. I can store it
in a global C variable, but then the entire application will be not
thread-safe. Locking the entire ml2c(); f(); c2ml(); section is also not
desirable...

Hope to hear from you soon,
Dmitry


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] camlidl and pointer to function

[NASSOR Eric]

[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]



Dmitry Bely wrote:

> I have a C library function with interface like following:
>
> typedef [abstract] void* SomeType;
> typedef int (*CallBack)(int);
> void convert( SomeType* in, SomeType* out, CallBack c);
>
> It would be nice to use it in caml the following way:
>
> external convert: someType->someType->(int->int)->unit = "something"
> ...
> convert stIn stOut ((+) 1)
> ...
>
> Unfortinately CamIDL language does not allow the pointer to function as a
> valid type, but maybe there is some common solution/workaround for this
> problem? Or the only way is writing necessary stubs and conversion
> functions by hands? Is is possible at all?
>

It is possible to call back caml code from a C code which was called from caml, but
you need to write a few lines of code.
here is an example extracted from my application (with a few simplifications).
the resulting caml function iter_tree can be called recursively, it can also raise
exceptions.

Another possible solution was proposed in a previous mail by Thierry Bravier, if
you want to use C++
http://caml.inria.fr/bin/wilma_hiliter/caml-list/199704/msg00029.html

Eric Nassor

-------------------------------------------------------------
in the original C library

typedef tree (*walk_tree_fn) (tree *, void *);

/* walk_tree iters on the tree data structure
  and calls the function func with the current tree value and the data
*/
tree walk_tree (tree *tp,  walk_tree_fn  func,  void *data)

-------------------------------------------------------------
in C_to_ml interface

/*
 * intermediary function called by walk_tree
 *  it calls the caml callback function which is given as argument
 */
static tree iter_tree_func(tree * t,void * fun)
{
  CAMLparam0();
  CAMLlocal1(tr);
/* if you want to stress the memory system */
/*  Garbage_collection_function() ;*/
  tr = camlidl_c2ml_type_tree(t,NULL);
  callback(*(value *)fun, tr);
  CAMLreturn(NULL_TREE);   /* caml exceptions are used if needed instead of  return
values */
}

/*
 * function to apply walk_tree to a CAML function
 */
value iter_tree (value v_function, value v_tree)
{
  CAMLparam2(v_tree, v_function);
  tree t ;
  camlidl_ml2c_type_tree(v_tree,&t,NULL);
  /* v_function is protected but its value may change because of the gc
     so we have to take the address */
  walk_tree(&t, iter_tree_func, &v_function);
  CAMLreturn (Val_unit);
}

camlidl_ml2c_type_tree and camlidl_c2ml_type_tree are  generated by camlidl to
translate tree between C and caml

-------------------------------------------------------------
in the caml code

external iter_tree :     (tree -> unit) -> tree -> unit  = "iter_tree"

-------------------------------------------------------------



[-- Attachment #2: Card for Eric Nassor --]
[-- Type: text/x-vcard, Size: 356 bytes --]

begin:vcard 
n:Nassor;Eric
tel;fax:+33 (0)2.99.84.11.30
tel;work:+33 (0)2 99 87 68 31
x-mozilla-html:FALSE
url:http://www.crf.canon.fr
org:Canon Research Centre France;Digital Design Department
version:2.1
email;internet:nassor@crf.canon.fr
adr;quoted-printable:;;Rue de la Touche Lambert=0D=0A;CESSON-SEVIGNE ;;35517 Cedex;France
fn:Eric Nassor
end:vcard

[Caml-list] camlidl and pointer to function

[Dmitry Bely]

I have a C library function with interface like following:

typedef [abstract] void* SomeType;
typedef int (*CallBack)(int);
void convert( SomeType* in, SomeType* out, CallBack c);

It would be nice to use it in caml the following way:

external convert: someType->someType->(int->int)->unit = "something"
...
convert stIn stOut ((+) 1)
...

Unfortinately CamIDL language does not allow the pointer to function as a
valid type, but maybe there is some common solution/workaround for this
problem? Or the only way is writing necessary stubs and conversion
functions by hands? Is is possible at all?

Hope to hear from you soon,
Dmitry


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr