[Ecls-list] Callbacks in ECL

[Juan Jose Garcia Ripoll]

On Wed, 2005-10-12 at 15:35 +0200, Goffioul Michael wrote:
> > I am not sure I understand this. The problem of callbacks, as I
> > understood it, is to produce _arbitrary_ C functions with any given
> > signature. I.e. functions like
> > 	int mycallback(int a, int b)
> > 	void mycallback(void *closure_data)
> > 	...
> > For this you need the type of code I committed already, and this is
> > precisely the type of callbacks that CFFI produces (and now also ECL)
> 
> Indeed, but I was trying to solve that problem at run-time, without the
> need of a compilation step. In other words, do the counterpart of DFFI.

But here my question is whether it does not suffice with a function
pointer plus some state data, as in the example I posed before. That can
be done with a single function implemented in ECL once and for all.

> > I wonder if this is actually needed in real life. I have never
> > personally found this in my life because C/C++ programmers typically
> > know that such a construct is probably not reentrant. Am I wrong? :-/
> 
> I admit I'm suffering a SEGFAULT in the full Win32 test case (I still
> have to investigate), but I know that at least the callback has been
> called re-entrantly up to level 3 without segfault.

I did not mean your code is not reentrant O:-) I meant that the a C library
cannot expect a C programmer to write an event handler which is
based on purely a function pointer, without some additional state
information, because otherwise the C programmer would have to store the
value in global variables and _that_ is likely not to be reentrant nor
thread safe.

I was mostly talking about the design philosophy of C/C++ libraries and
what type of callbacks you need to interact with them.

But again I have not much real life experience outside of the world of
numerics in which I spend my working time, so I might be wrong.

Regards,

Juanjo