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

[Boris Dores]

On Mon, Oct 22, 2007 at 02:35:10PM (GMT+0200), Rémi Denis-Courmont wrote:
> Sure, the managed wrapper should protect the unmanaged code, and prevent

  That's exactly what I said, I didn't imply that it would be magical :)

> the managed code from doing undefined unmanaged operations. Alas, taking
> such things as multiple CLR threads, and other such funny as managed
> thread cancellation, makes this pretty difficult, if at all possible.

  Difficult, maybe, but I don't see in which way the additional .net
layer changes anything to the issue:

- either the crash is a bug and must be corrected one way or another,
  by protecting the managed code or the unmanaged code (which can then
  return an error code converted to an exception in the managed code for
  instance)

- either we consider it's a "feature" which can't be corrected or would
  be too difficult to correct, and I don't see why we asked to the GC of
  the CLR to magically solve it in the first place

  However, to do a refcount, it will be necessary to handle those same
threading issues, right ? So why wouldn't it be possible to handle them
to only check if the master object was destroyed ?

  And anyway, is it really necessary that the CLR accesses several
threads of libvlc ? Shouldn't this management interface be synchronized
? I don't know the answer to this question, I'm simply curious.

  Finally, if you are only talking about multiple threads created by the
user in their own application, then that's not an issue either, because
that's their role to synchronize their threads to access libvlc, just
like with the vast majority of managed classes which are not thread
safe.

-- 
Boris Dorès