c event handling - how?

[Phui Hock]

Hi,
How do I generate an event and got it handled by a handler? I know
how to do it in C++ or Java but I got no idea how to do it in C. What
is the best approach to write a function that will take a function
pointer, a pointer to user data (what is it?) and then I notify it
when a certain event happens?

I'm new to C, btw

Thanks a lot for helping.

 

[Mark A. Odell]

(e-mail address removed) (Phui Hock) wrote in

Hi,
How do I generate an event and got it handled by a handler? I know
how to do it in C++ or Java but I got no idea how to do it in C. What
is the best approach to write a function that will take a function
pointer, a pointer to user data (what is it?) and then I notify it
when a certain event happens?

You mean call back? I don't think that you can in C. There are no threads,
interrtups, or tasks in C. You can see if setjmp/longjmp() are of interest
but I doubt standard C will allow you to do what you want without
platform-specific extensions (which are off-topic here).

 

[Lew Pitcher]

(e-mail address removed) (Phui Hock) wrote in





You mean call back? I don't think that you can in C.

Well, you can.

> There are no threads,
Correct

interrtups,

Sort of wrong. Hardware level interrupts aren't supported as such, but an
abstraction of interrupts (as a general concept) /is/ supported.

or tasks in C. You can see if setjmp/longjmp() are of interest
but I doubt standard C will allow you to do what you want without
platform-specific extensions (which are off-topic here).

See the signal() and raise() functions in the Standard, along with signal.h

 

[Mark A. Odell]

What the OP asks for include, but is not restricted to, callbacks.


Do what ? callbacks ? yes you can. Have a look at the (standard) qsort()
function. It takes a callback function as lsat argument.

Not what I meant, of course you can pass a function a pointer to a
function but the function you just called with this pointer can't call you
back without recursion. By callback I meant called by some other task or
an interrupt service routine. Apparently signal() and raise() can do some
level of this as Lew pointed out.

 

[Bruno Desthuilliers]

(e-mail address removed) (Phui Hock) wrote in





You mean call back?

What the OP asks for include, but is not restricted to, callbacks.

I don't think that you can in C.

Do what ? callbacks ? yes you can. Have a look at the (standard) qsort()
function. It takes a callback function as lsat argument.

(snip)

Bruno

 

[E. Robert Tisdale]

How do I generate an event and get it handled by a handler?
I know how to do it in C++ or Java
but I have no idea how to do it in C.

Show us how you would do it in C++.

What is the best approach to write a function
that will take a function pointer,
a pointer to user data (what is it?)
and then I notify it when a certain event happens?

Show us an example of what you mean in C++.

 

[Lew Pitcher]

Not what I meant, of course you can pass a function a pointer to a
function but the function you just called with this pointer can't call you
back without recursion. By callback I meant called by some other task or
an interrupt service routine. Apparently signal() and raise() can do some
level of this as Lew pointed out.

Specifically, signal() accepts a pointer to the function to be "called
back", and a value indicating the signal that will invoke the callback.

raise() accepts a value that will be used as the value of a signal. When
raise() is invoked, the signal is "sent", and asychronously, the callback
function associated to that signal by a previous signal() call will be called.

There are limitations on what the callback function can and cannot do, so
don't go coding complex logic into it (i.e. no printf() statements, etc.).

 

[Alex]

Phui Hock wrote:

Show us how you would do it in C++.

Not here.

Show us an example of what you mean in C++.

Not here.

Alex

 

[Bruno Desthuilliers]

Not what I meant, of course you can pass a function a pointer to a
function

I sure guess you know this !-)

I just wanted to clarify that point for the OP and C beginners reading this.

(sorry, I s/c/sh/ould have stated this more explicitely).

Bruno

 

[PH]

By callback I meant called by some other task or

an interrupt service routine.

What I've learned from another is to create a table and map events to
function pointers (array or linked list). So I do this:-

typedef void (*callback) (void *);
struct event_handlers {
callback cb;
struct event_handlers *next;
} listeners[SIZE];

And I have an event registration function like this:-
void register_event(int event, callback cb) ...

When an event happens:-
event_handlers *handler = listener[event]; /* event is mapped to
event_handers */
for(; handler != NULL; handler = handler->next)
handler->cb(data);

I also learned that I can create a hash table to map events to function
pointers. As the number of new events grow, we can realloc to accommodate
those.

Is this the best approach?

Apparently signal() and raise() can do some
level of this as Lew pointed out.

With signal() and raise(), I can't pass my own data to the target function
(except via global variable, which I think, is ugly).

 

[Anuj Heer]

buddy

in c u can use the setvect and getvect functions to apture standard
interrupts and make them point to your code thus making event handling
much simpler....but do remember to call the original isr at the end of
your routine so that the interrupt is not lost and also set the vector
to the original pointer at the end of your program unless you want to
reboot every time your program ends...
u did not specify the type of event handling you are looking for..
do contact me if you need more information on this topic

(e-mail address removed)

 

[Joona I Palaste]

buddy

in c u can use the setvect and getvect functions to apture standard
interrupts and make them point to your code thus making event handling
much simpler....but do remember to call the original isr at the end of
your routine so that the interrupt is not lost and also set the vector
to the original pointer at the end of your program unless you want to
reboot every time your program ends...
u did not specify the type of event handling you are looking for..
do contact me if you need more information on this topic

(e-mail address removed)

The C language does not define setvect, getvect, isr or anything
like that. You want a system-specific newsgroup.

 

[Richard Heathfield]

buddy

in c u can use the setvect and getvect functions to apture standard
interrupts

C has no functions called setvect or getvect.

 

[Mike Wahler]

buddy

in c u can use the setvect and getvect functions to apture standard
interrupts and make them point to your code thus making event handling
much simpler....but do remember to call the original isr at the end of
your routine so that the interrupt is not lost and also set the vector
to the original pointer at the end of your program unless you want to
reboot every time your program ends...
u did not specify the type of event handling you are looking for..
do contact me if you need more information on this topic

Sigh. Yet another "all the world's an Intel box" person.
Please read the FAQ.

-Mike

 

[CBFalconer]

in c u can use the setvect and getvect functions to apture standard
interrupts and make them point to your code thus making event handling
much simpler....but do remember to call the original isr at the end of
your routine so that the interrupt is not lost and also set the vector
to the original pointer at the end of your program unless you want to
reboot every time your program ends...

Please stop giving such erroneous information. There is a saying
about keeping silent and allowing people to wonder if you are an
idiot, and speaking up and confirming their suspicions.

It is bad enough that someone may actually use your
misinformation, but in addition you are causing all sorts of extra
traffic here simply to correct and warn about it.

 

[Dan Pop]

Sigh. Yet another "all the world's an Intel box" person.

Well, I'm using an Intel box too, but I can't find any trace of setvect
or getvect on it. I must be missing something...

Dan

 

[Joona I Palaste]

Well, I'm using an Intel box too, but I can't find any trace of setvect
or getvect on it. I must be missing something...

So all the world is not just an Intel box, it's a very special kind of
Intel box, then.

 

[Dave Thompson]

Specifically, signal() accepts a pointer to the function to be "called
back", and a value indicating the signal that will invoke the callback.

raise() accepts a value that will be used as the value of a signal. When
raise() is invoked, the signal is "sent", and asychronously, the callback
function associated to that signal by a previous signal() call will be called.

Handling of raise'd signals (and abort) is synchronous; 7.14.2.1p2. It
is signals caused from outside the process, or at least thread -- in
particular, in a POSIX environment, by kill -- that can be
asynchronous, but that is out of scope of standard C and clc.

There are limitations on what the callback function can and cannot do, so
don't go coding complex logic into it (i.e. no printf() statements, etc.).

A signal handler only called for/by a raise'd signal (or abort) can do
anything (an ordinary function can) because those can only have
occurred in user code. A handler for a "true" signal like SIGSEGV is
not guaranteed to be able to use anything in the library, although in
practice the purely computational stuff like string.h, ctype.h, *abs
and *div, and probably math.h, complex.h and tgmath.h, will work, as
almost certainly will stdarg.h and the compile-time stuff. But in at
least some environments a program can't prevent asynchronous
occurrence of a handled signal, so the handler must always be safe.

- David.Thompson1 at worldnet.att.net

 

[Dave Vandervies]

A signal handler only called for/by a raise'd signal (or abort) can do
anything (an ordinary function can) because those can only have
occurred in user code.

Except call raise() (N869 7.14.1.1#4).

(I'm not sure whether a "reasonable implementation" would have problems
with this - the obvious way of implementing it is to do something
like "sighandler_funcs[signum](signum);" (except in POSIXish systems,
where the man pages I have access to document it as being equivalent to
"kill(getpid(),sig)"), but something that does weird stuff inside raise()
need not jump through hoops to make it reentrant.)


dave

--