XS: Passing an external library's function a Perl XS callback - c

Disclaimer: asked over at perlmonks.
I hope I'm describing and depicting my issue properly... In XS, I'm trying to send a callback into an external library's function, where the callback has Perl specific functions. The XSUB is passed as a function pointer to an external C function. The XSUB callback being sent in turn calls back to a sub in the `main` perl application:
void callback(){
dSP;
PUSHMARK(SP);
call_pv("p_callback", G_DISCARD|G_NOARGS);
}
// example extern call
externFunc(&callback);
This segfaults. I think it's because the external library doesn't understand the perl functions that are being called. Things work fine if I call the C `callback()` function directly though.
Is there some magic that I can do to make the external library "see" the Perl C functions, or am I doing something wrong?
Here's the code I'm testing with:
use warnings;
use strict;
use Inline ('C' => 'DATA', libs => '-lwiringPi');
init();
setInterrupt(27, 3);
# direct call
callback();
# on() triggers the external function and sends
# it the callback
on(27);
sub p_callback {
print "in perl callback\n";
}
__DATA__
__C__
#include <stdlib.h>
#include <stdio.h>
#include <wiringPi.h>
void init();
void on(int pin);
void off(int pin);
void setInterrupt(int pin, int edge);
void callback();
void init(){
printf("in init\n");
wiringPiSetup();
}
void on(int pin){
pinMode(pin, 1);
digitalWrite(pin, 1);
}
void off(int pin){
digitalWrite(pin, 0);
pinMode(pin, 0);
}
void setInterrupt(int pin, int edge){
wiringPiISR(pin, edge, &callback);
}
void callback(){
dSP;
PUSHMARK(SP);
call_pv("p_callback", G_DISCARD|G_NOARGS);
}
Output:
in init
in perl callback
Segmentation fault
If I remove the perl specific C calls from within the callback and just do a `printf()` or other pure-C work, things proceed without a segfault.

Just came across this question and thought I'd give it my own answer as I did resolve it some time ago.
There were some important bits I was missing to set the Perl context, as well as within the C exec_perl_callback() function.
use warnings;
use strict;
use Inline 'C';
use Inline 'NoClean';
sub p_callback {
print "hello, world from perl!\n";
}
exec_perl_callback('p_callback');
__END__
__C__
#define PERL_NO_GET_CONTEXT
PerlInterpreter * mine;
void callback(char* perl_callback){
PERL_SET_CONTEXT(mine);
dSP;
ENTER;
SAVETMPS;
PUSHMARK(SP);
PUTBACK;
exec_perl_callback(perl_callback, G_DISCARD|G_NOARGS);
FREETMPS;
LEAVE;
}
Output:
hello world, from perl!

Related

C is there a workaround to allow dynamic function calls?

I have read that C does not support dynamic function calls. My program has an ever growing number of test cases implemented as separate functions like -
int testcase1(void);
int testcase2(void);
int testcase3(void);
Each time I add a new test case, I also have have to add the call to my main function like -
int main(int argc, char **argv){
assert(!testcase1());
assert(!testcase2());
assert(!testcase3());
}
I would prefer to call something like assert(!testcase*()) where * matches any string which resolves to a valid function name in my program.
Can you think of a more convenient solution?
If you all your testcases have same signature then you can use an array of function pointers:
void (*func[])() = { testcase1, testcase2 };
for (size_t i = 0; i < sizeof(func)/sizeof(func[0]); i++) {
assert(!func[i]());
}
The best solution is likely to write a few extra lines of code when you add new test cases - it really isn't a big issue. I would recommend something along the lines of the function pointer array, as suggested in another answer.
However, just to show that everything is possible in C if you throw ugly macros at the problem, here is a not recommended alternative:
#include <assert.h>
#include <stdbool.h>
#include <stdio.h>
#define TEST_CASES \ // list of "x macros"
X(testcase1) \
X(testcase2) \
X(testcase3)
#define X(func) bool func (void); // declare function prototypes
TEST_CASES
#undef X
bool (*const test_cases[])(void) = // array of read-only function pointers
{
#define X(func) &func, // point at each function
TEST_CASES
#undef X
};
int main (void)
{
for(size_t i=0; i<sizeof(test_cases)/sizeof(test_cases[0]); i++)
{
assert(test_cases[i]());
}
}
bool testcase1 (void) { puts(__func__); return true; }
bool testcase2 (void) { puts(__func__); return true; }
bool testcase3 (void) { puts(__func__); return false; }
Output:
testcase1
testcase2
testcase3
Assertion failed!
For each new test case, you would only have to write a function definition and then add it to the "x macro" list TEST_CASES. However, you need very good reasons to introduce ugly tricks like these in production code!
You can use function pointers. Read also about closures (but C99 or C11 don't have them) and callbacks.
Many operating systems provide dynamic loading. On POSIX operating systems (such as Linux or MacOSX) you can get a function pointer (actually an address) from its name in some library (or in the program executable) using dlopen & dlsym. Other operating systems may provide similar functionalities.
At last, you should consider having your testing main function be generated by some script (or some program emitting C code), using metaprogramming techniques. So you would write something which generates the C code of your testing main having a long sequence of assert, and improve your build procedure (e.g. your Makefile if using make) to run appropriately that specialized C code generator. Details are of course specific to your code. You might add some conventions (e.g. add some special comment to be parsed by your test generator, etc...).
I decided to follow #Nominal Animal and #Basile Starynkevitch's approach. In mymainprog.c, I added -
int runtests(void){
void *testh;
int (*testp)(void);
char *dlmsg;
int rc;
char funcname[8];
int testnum;
testh = dlopen("libsmtests.so", RTLD_LAZY);
if (!testh){
printf("%s\n", dlerror());
return 1;
}
dlerror();
for (testnum =1; testnum < 1000; testnum++){
sprintf(funcname,"testcase%d", testnum);
*(void **) (&testp) = dlsym(testh, funcname);
dlmsg = dlerror();
if (dlmsg == NULL) {
rc = (*testp)();
printf("%s called, rc=%d\n", funcname, rc);
}
}
dlclose(testh);
return 0;
}
I add my testcases to a separate file (testcases.c) like this -
int testcase1(void){
return [some testcase expression]
}
int testcase2(void){
return [another testcase expression]
}
and then compile it as a shared library with position-independant code (-fPIC) to libsmtests.so. The advantage is slightly less typing since I don't need to code a call to testNNNN() after adding the implementation of a new functionint testcaseNNN(void) to testcases.c

Unable to call a C function from Lua-lanes

While trying to call a C function from Lua module, using Lua-lanes, the control doesn't transfer to the 'C' function. Is there any problem with which Lua-lanes won't work in a threaded way with an external C dll?
Below is the code snippet
Lua Snippet:
lanes.gen("*",func)
thread = func()
thread:join()
function func()
foo() -- expected to print "Hello world", by
-- calling below C function,but not happening
end
C snippet compiled to a dll with VS-2012:
static int foo(lua_state *L)
{
printf("Hello world\n")
}
If you want that C function accessible in the new thread then you have to somehow transfer that from the main lua thread over to the new thread when you create the lane. You can do this by using .required from the lua-lane docs.
For example, say you have this simple foomodule:
// foomodule.c
// compiles to foomodule.dll
#include <stdio.h>
#include "lua.h"
#include "lauxlib.h"
static int foo(lua_State *L)
{
printf("Hello world\n");
return 0;
}
int luaopen_foomodule(lua_State *L)
{
lua_pushcfunction(L, foo);
lua_pushvalue(L, -1);
lua_setglobal(L, "foo");
return 1;
}
And from your lua script:
// footest.lua
lanes = require 'lanes'.configure()
function func()
print("calling foo", foo)
return foo()
end
thr = lanes.gen("*", {required = {'foomodule', }}, func)
thr():join()
One possible output:
calling foo function: 0x003dff98
Hello world
You are using lanes wrong. This is what you need to do:
function func()
foo() -- expected to print "Hello world", by
-- calling below C function,but not happening
end
local launcher = lanes.gen("*", func)
thread = launcher()
thread:join()
That should work fine.

cython segmentation fault handling

I am wrapping some C library, and I have one function which in some cases may result with segmentation fault. In that case I need to call second function, which will in that situation complete successfully.
Does anyone knows how can I handle segmentation fault in cython?
A short example that might help (using signal):
example.h (assuming the Cython extension is named myext.pyx)
// Header autogenerated by Cython when declaring "public api" functions
#include "../myext_api.h"
void handleFuncFailure(char *func1_name, char *func2_name);
void generateSegFault();
example.c
#include <example.h>
#include <signal.h>
static char *func2name;
static void handler2(int sig)
{
// Catch exceptions
switch(sig)
{
case SIGSEGV:
fputs("Caught SIGSEGV: segfault !!\n", stderr);
break;
}
int error;
// "call_a_cy_func()" is provided by "myext.pyx"
call_a_cy_func(func2name, &error);
exit(sig);
}
void handleFuncFailure(char *func1_name, char *func2_name) {
// Provided by autogenerated "myext_api.h" header
import_myext();
func2name = func2_name;
signal(SIGSEGV, handler2);
int error;
// "call_a_cy_func()" is provided by "myext.pyx"
call_a_cy_func(func1_name, &error);
}
void generateSegFault() {
*(int*) 0 = 0;
}
myext.pyx
# Helper function to call a function by its name
# "public api" enables to call this function from C side (See above)
cdef public api void call_a_cy_func(char* method, bint *error):
if (method in globals()):
error[0] = 0
globals()[method]();
else:
error[0] = 1
# Expose C functions
cdef extern from "src/example.h":
void handleFuncFailure(char *func1_name, char *func2_name)
void generateSegFault()
# The unreliable function
def func1():
print "hello1 ! Generating segfault..."
generateSegFault()
# The reliable function
def func2():
print "hello2 ! Running safe code..."
# To be called from the Cython extension inner code
cdef myHandleFuncFailure(f1, f2):
handleFuncFailure(f1, f2)
# To be called from Python source by importing "myext" module
def myHandleFuncFailure2():
myHandleFuncFailure("func1", "func2")
Ouput
hello1 ! Generating segfault...
Caught SIGSEGV: segfault !!
hello2 ! Running safe code...
I hope this gives some ideas, at least...

Implementing callback functions in C

I am a newbie to C. I am trying to implement callback function using function pointers.
I am getting an error
:test_callback.c:10: error: expected identifier or ‘(’ before ‘void’
when I try to compile the following program:
#include<stdio.h>
void (*callback) (void);
void callback_proc ()
{
printf ("Inside callback function\n");
}
void register ((void (*callback) (void)))
{
printf ("Inside registration \n");
callback (); /* Calling an initial callback with function pointer */
}
int main ()
{
callback = callback_proc;/* Assigning function to the function pointer */
register (callback);/* Passing the function pointer */
return 0;
}
What is this error?Can anyone help?
register is a C keyword: Use another name for the function.
You have extra parantheses around the callback parameter. It should be:
void funcName(void (*callback) (void))
I would recommend to use a typedef
#include<stdio.h>
typedef void (*callback_t) (void);
callback_t callback;
void callback_proc(void)
{
printf ("Inside callback function\n");
}
void reg( callback_t _callback )
{
printf ("Inside registration \n");
_callback();
}
int main ()
{
callback = callback_proc;
reg(callback);
return 0;
}
EDIT: removed the register issue
You can't use 'register' as a function name as it's a C keyword.
2 problems:
you can't use the name register as it's a keyword (not used often anymore, but it's still there)
change the definition of the function from
void wasRegister((void (*callback) (void)))
to:
void wasRegister(void (*callback) (void))
(get rid of the parens around the parameter's declaration.
Also you might get a warning about callback_proc() not having a matching delaration to the callback variable (depending on how you compile the program - as C or C++), so you might want to change its declaration to:
void callback_proc (void)
to make it explicit that it takes no parameters.
Have a look at type safe callbacks from ccan. Its one thing to expose a typed function pointer for the world to use, its another to ensure sane casting.
#include<stdio.h>
typedef void (*callback_func) (void);
static callback_func the_callback = 0;
void process (void)
{
printf ("Inside process function\n");
}
void callback_register (callback_func cb)
{
the_callback = cb;
printf ("Inside registration \n");
}
void callback(void)
{
the_callback();
}
int main (void)
{
callback_register(process); /* Passing the function pointer */
callback();
return 0;
}
Declaring the_callback static would make more sense if this code was modularized and then you would be forced to call callback_register in order to set it, and callback in order to call it - the_callback would not be accessible outside of the implementation (.c) only the function declarations would be in the header (.h).

How to call a function just before returning in C?

I'm trying to execute something at the end of a function just before it returns to the caller.
To Do so, I would like to override return in a certain context. The behavior should be the same as __cyg_profile_func_exit, but I would like to activate it only for some functions.
I don't know if it's possible using gcc builtins or this kind of thing.
Thanks.
GCC has an attribute for this, which calls a function when an automatic variable goes out of scope, passing it the address of that variable
void cleanup_fn(int *p) {
puts("cleanup called...");
}
void f(void) {
int p __attribute__((cleanup(cleanup_fn)));
puts("in f...");
}
int main(void) {
puts("calling f...");
f();
puts("out of it...");
return 0;
}
Output:
calling f...
in f...
cleanup called...
out of it...
Nope, not in C per se.
What you could do is write a #define macro RETURN:
#define RETURN(func) if(_DEBUG_) func; return ;
#define RETURNV(func, val) if(_DEBUG_) func; return val ;
(Warning, you probably want to think a little more about guarding special cases than I have.)
Otherwise, you would need to write something that mangled the code behind the scenes, which is what profilers do.

Resources