Socket calls from timer functions (server based)
Smith, Gene SEA
Gene.Smith at siemens.com
Wed Apr 13 12:55:20 UTC 2005
> -----Original Message-----
> From: Paul Whitfield [mailto:paulw at omnitronics.com.au]
> Sent: Tuesday, April 12, 2005 10:58 PM
> To: Ian Caddy
> Cc: Smith, Gene SEA; rtems-users at rtems.com
> Subject: Re: Socket calls from timer functions (server based)
> Ian Caddy wrote:
> > Hi Gene,
> > As far as I am aware, the TSRs run in the context of the timer
> > interrupt service routine, which means you can only perform
> > that are safe in interrupts.
> > Network functions are generally not safe to call from
> interrupts, as
> > most network functions are blocking functions.
> > You will probably need to find another way to implement
> this, such as
> > sending an event or message to a thread that can perform
> the setsockopt.
> From the OP's email he is using server based timers (not
> present in rtems 4.5).
> In this case the timers run in the context of the timer server task.
> As noted in OP: In the time server Thread dispatching is disabled.
> The previous advice is probably still the best idea, don't
> call network functions from the context of a TSR. Generate an
> event or message and call the network function from a
> application task.
> My reasoning for this is:
> TSR's are still "special" functions, they are run at the
> highest task priority and should be very "quick"
> and never block.
As an aside, there appears to be a error in the c user manual 4.6.1 and
4.6.2 editions that leave out the first parameter of
rtems_timer_initiate_server() that specifies the priority of the timer
server task. There is a constant RTEMS_TIMER_SERVER_DEFAULT_PRIORITY
which can provide the highest priority value to the task as the first
parameter. So it appears you can actually give the timer server task a
lower than maximum "default" priority. Yet it is still not dispatchable.
> All timers are processed from the one loop and delays as a
> result of processing on TSR will effect all the other timers.
> Any function with the possibility of blocking should not be
> called from a TSR. Network calls can block (even setting
> socket options as they need to access mutex's) so therefore
> should not be called from a TSR.
Well right now I only have one timer so delays to others are not an
issue (yet). However, I see your point and will go ahead and just use a
regular (non-server based) timer to trigger a user task to do the socket
> Hope that make sense.
Yes, thanks for noticing I was referring to server based TSRs!
More information about the users