[vlc-devel] CIL bindings and brain dump on LibVLC

[Boris Dores]

On Sun, Oct 21, 2007 at 10:36:07PM (GMT+0300), Rémi Denis-Courmont wrote:
> For the reference, CIL provides a grand total of six integers types, which 
> corresponds to the following C99 types: int8_t, int16_t, int32_t, int64_t and 
> intptr_t and bool. Note that "int" is not directly supported - I am currently 
> assuming it is int32_t, which works by far on most platforms (at least all 
> 32-bits platform as well as x86_64). But it might break :-(

  If a true C int is unavoidable, the corresponding CIL type would
be IntPtr, even if the name is somewhat misleading ( from MS
doc: "The IntPtr type is designed to be an integer whose size is
platform-specific. That is, an instance of this type is expected to be
32-bits on 32-bit hardware and operating systems, and 64-bits on 64-bit
hardware and operating systems." )

> It gets interesting when you consider that you cannot provide native "glue" C 
> code here, since it would defeat the whole CIL concept of "compile once, run 
> anywhere". In other words, any piece of code beyond libvlc-control is to be 
> compiled in CIL. So basically, anything that uses int may be somewhat broken, 
> and anything that uses bool or enum is somewhat more likely broken.

  But you can provide the import class (and possibly the corresponding
precompiled library for various platforms) which will do all the
necessary checks, conversions and dirty work and so will not be broken
(lots of things can be done in such an import library).

> The other big problem I have had is the lack of reference counting on 
> libvlc_instance_t. The garbage collector ensures that any allocated 
> libvlc_instance_t will be released with libvlc_destory, but it cannot warrant 
> that any other dependent LibVLC object such as a media instance or a media 
> descriptor will not similarly be released *after* libvlc_instance_t... and 
> then, it does actually crash the whole process :-(

  If a release order (from the CIL point of view) is unavoidable or if a
resource must be freed at a specific time, implement IDisposable (of
course, if the native library is designed not to need it, it's better).

  One good source of reference and tips beyond MS doc on this subject is
<http://www.mono-project.com/Interop_with_Native_Libraries>.

-- 
Boris Dorès