posix timers
 

hi,
I'm using posix timers..is there any way to put argument to the sigevent function other than signum..pls help me
Thanks

hi,
as i know sigevent is a structure, not a function.

Could you describe more clearly what you mean?

Moved to Programming

struct sigaction act;

sigfillset(&act.sa_mask); /* Set up signal handler */

act.sa_flags = 0;

act.sa_handler = userfunction; //userfunction is set as the function to be + called when a signal event occures.



sigaction(signum, &act, NULL)
struct sigevent se;
se.sigev_notify = SIGEV_SIGNAL;
se.sigev_signo = signum;
se.sigev_value.sival_int = 0;

timer_create(CLOCK_REALTIME, &se, &timer_id)


Here the problem is when the timer fires, only the signum (by default)is available in the userfunction. Can i pass any other arguments other than that.

And also i'm able to use only SIGRTAX number of timers. ie 32 or 64.. but i want to use more than that...say 250 timers at a time

Thanks..

As an aside -

If you have a large number of timers, then you will have timer events going off constantly, possibly creating a lot of timer overruns - meaning more processing time required per jump to the function, since you have to worry about overruns.

I think you have a design problem. What exactly are trying to do?
Somebody here has probably already done it.

Actually i'm trying develop a wrap around for posix timers. So that the application developer can use my timer function instead of using the posix timer directly. And also i need to provide a minimum of 100timers working at a time. Say if a tcp/ip application may need many timers..ie for each packet a timer is assosiated. Its just an example.. Hope u understood the situation.
Thank you..

I'm sorry I just don't understand the logic to your example of why you would need a hundred timers, why would a packet using TCP need a timer? TCP is a connection orientated protocol which guaranties delivery once sent unless the connection is broken. If using UDP and wanting to implement your own guaranteed delivery on top then I could maybe understand the need for a timer, but personally I would still not use a timer as such more a time stamp and a delivery window.

Your answer to this question is partially right but its also wrong. TCP was designed for connectionless networks. As stated in Tanenbaum's Computer Networks 4th Ed, TCP was specifically designed to provide a reliable end-to-end byte stream over an unreliable network. Over unreliable networks like 802.11 wireless networks packets can get lost and TCP uses timers at the sending end to wait for an acknowledgment. That said I would not call TCP a connection oriented protocol but a connectionless oriented protocol that makes a reliable connection possible over an unreliable network layer. However because the Internet is mostly based on TCP/IP, TCP is also used on connection oriented networks for the purpose of accessing the Internet and people somehow have this assumption that TCP is connection oriented which is wrong.

In general you are right when you say there is no need for a timer on packets when using TCP. However for educational organizations that need to do research on TCP or for a networking class in the Computer Science department of a University that requires a student to implement a transport entity similar to TCP for the purpose of learning, then it becomes practical to have timeouts on packets even if TCP sockets are being used to make connections. I took a course like this at the University of Illinois and I had an assignment similar to this. Timers were absolutely necessary because the requirements called for the ability to emulate an unreliable network layer and to demonstrate knowledge by showing that the transport layer actually does create a reliable byte stream under the conditions of an unreliable network layer. In addition when the assignment calls for the server to support multiple connections, the need for multiple timers is essential because using just one timer will have a negative impact on performance.