rtems select implementation

[John Wood]

Another alternative which is likely the best for now is to add an additional descriptor and have my timer send a byte to it to interrupt the select call.

-----Original Message-----
From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] On Behalf Of John Wood
Sent: Thursday, September 02, 2010 1:44 PM
To: Eric Norum
Cc: rtems-users at rtems.org
Subject: RE: rtems select implementation

Here is what I tested for my select implementation...

	rtems_event_set event_in = SBWAIT_EVENT | SBCATCH_EVENT;


...


				break;
			then = now;
		}
		rtems_event_receive (event_in, RTEMS_EVENT_ANY | RTEMS_WAIT, timo, &events);
		if ( events == SBCATCH_EVENT )
			break;
	}

This seems to work quite well.  

Regards,
John






I am waiting on 2 sockets, the ptp event and general interfaces.  I can add a timeout in the code that calls select easily enough, but it is not a nice as having select interrupted by my timer events similar to a signal in linux.  If I add a timeout and want the system to behave similarly to its linux counterpart I would need a small timeout which results in much more task switching vs. a less responsiveness due to a longer timeout.

Alternatively, if select were implemented waiting on not only SB_WAIT but say SB_CATCH for example, then a timer could calls rtems_event_send with SB_CATCH and this could abort select.  This could possibly allow a closer implementation of select with its BSD equivalent if someone was using posix signals for example.

The main reason I don't want to just use a timeout is that it has an effect on the overall ptpd state machine.  There are actually 5 timers that can result in select being aborted which then allows the state machine to go to various states depending upon which state it is currently in and what timer has timed out.  The timeouts are all different of course.  I believe this to be the reason it was changed from a timeout based system in select.  

Thanks,
John   

-----Original Message-----
From: Eric Norum [mailto:wenorum at lbl.gov] 
Sent: Thursday, September 02, 2010 12:40 PM
To: John Wood
Cc: rtems-users at rtems.org
Subject: Re: rtems select implementation

The socket receive and send timeout options work on RTEMS.
If you have to wait on only one socket per thread this might be an option for you.

On Sep 2, 2010, at 9:30 AM, John Wood wrote:

> Greetings all, 
> 
> 
> I have a question about the best way to implement something using the select function call, ideally I don't want to pull in the posix interface.
> 
> I am porting ptpd, the precision time protocol for use with my board using rtems.  My goal is to minimize modifications to the ptpd code base as much as possible.  I ran into an interesting problem when I went from version 1 of the ptpd code to version 2.  Specifically, in the original implementation the code calls select with a non null value for the timeout.  Various timers are running in the background and when select would timeout it would check to see if the appropriate timeout had  expired.  Since there was a timeout in select this masked an issue with the rtems version of select.  In version 2, the code was changed to have a null timeout.  The linux implementation of the timers used signals so select would exit on the timer event.  This was masked in my implementation.
> 
> After figuring this out, I thought all I need to do was to send SB_WAIT to the task calling select from my timer callback.  Easy enough, however in rtems select if the nothing is ready in any of the fd lists then the select function will simply call rtems_event_receive.
> 
> I have a couple options here.
> 
> 
> 1. use posix and verify the signals work the same way
> 2. modify rtems_select, obviously not desired (any chance this is in the works?)
> 3. modify the ptpd interface to use timeouts
> 
> Each has its own drawbacks
> 1. Posix...size, complexity and I am currently using rtems++ and native rtems everywhere else
> 2. Kindof nasty modifying the internals of rtems 
> 3. having the timer trip select results in a more responsive system, also would like to keep the protocol engine for ptpd as close as possible.
> 
> Any suggestions?
> 
> Thanks a lot,
> John
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users

-- 
Eric Norum
wenorum at lbl.gov


_______________________________________________
rtems-users mailing list
rtems-users at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-users