Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Caml Wrappers
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] Caml Wrappers
From: Ravi Chamarty <ravi@ittc.ukans.edu>

>  I am trying to write OCaml interfaces around a C library.  I tried
> looking at the Unix library and trying to understand it. However, I have
> much complex data types to deal with.I was wondering if anyone could help
> me out. 
> 
> Here is a signature of one of the C functions:
> 
> an_flow_t * 
> an_flow_create(void *mem, an_cred_t *cred, an_cpuspec_t *cspec,
> 		an_memspec_t *mspec, an_flowinit_func_t init, 
> 		void *initarg, an_flowterm_func_t term)
> 
> 
> Each of these types are complex structures in C. How do I represent these
> in OCaml. Is it useful to use classes and methods? Or do I use abstract
> types to represent them ?

Classes and methods would be no help. You can use them later to wrap up
an abstract datatype, if it is really heavily used, but generally you
won't need them.

The real choice is rather between using an abstract datatype wrapping
a pointer to the C structure, or converting to a caml data structure
(records, and eventually sums).  This essentially depends on whether
you have control on when these structures will be freed: if they can
disappear suddenly, then it means that with abstract datatypes, you
could have a stale pointer on the caml side. Then the only safe
approach is to convert, which Unix does in almost all cases.

If you can decide when to deallocate these structures, then abstract
datatype is a potential approach.  The advantage is that you don't
need to convert back C values to caml, with all the gory GC details.
You just define accessor functions in C, and call them from caml.
Most of lablgtk is done that way, but it is a bit overly complex
because it also uses automatic deallocation (finalized pointers) which
you do not necessarily need. A simpler example is the Dbm library in
the standard distribution.

> An example of one of these structures is given below:
> 
> struct an_flow_t {
>   struct hnode me; 	  /* flow hier link (must be first) */
>   struct ani_cred *cred;  /* credentials */
>   struct ani_mempool *mpool;  /* mempool */
>   struct ani_chan *chanlist;  /* list of channels */
>   struct ani_threadpool tpool;  /* thread pool */
>   int flags;  /* various flags */
>   an_flowterm_func_t termfunc; /* termination function */
>   ani_resource_t res;  /* reserved resources */
>   int refs;  /* reference count */
>   ani_ilock_t lock;  /* mutual exclusion */
>   an_flowstats_t stats;  /* statistics */
> };   
> 
> 
> I would be grateful for any help.
> 
> Thanks
> Ravi
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr
> 
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr