Socket calls from timer functions (server based)

[Smith, Gene SEA]

> -----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 
> operations 
> > 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
stuff.

> 
> Hope that make sense.

Yes, thanks for noticing I was referring to server based TSRs!
-gene

> 
> Regards
> 
> 
> Paul
>