Re: [reSIProcate-users] Optimization of Random class, threads and epoll

[Kennard White <kennard_white@xxxxxxxxxxxx>]

Hi Francis,

Thanks for your comments -- it is useful to know what other developers care about.

With the "new" callback style, it is even easier for your app to use the sip stack's event loop/thread to monitor your own "private" socket. I'll add instructions on how to do this to the wiki page. But the essence is that your app has to implement The FdPollItemIf interface, and then call addPollItem(), modPollItem(), and delPollItem() on the FdPollGrp instance. Or your app can subclass from FdPollItemBase and you can save some typing. There is no need to subclass EventStackThread.

To add private app timers you would still do it the traditional way: subclass EventStackThread, and define getTimeTillNextProcessMS() to get the time of your lead timer and afterProcess() to run any expired timers. Hmm, I left out afterProcess() -- I'll add that in.

Regards,
Kennard

On Tue, Mar 1, 2011 at 6:49 AM, Francis Joanis <francis.joanis@xxxxxxxxx> wrote:

Hi Kennard,

Thanks a lot for those updates.

Regarding the SipStack Event Loop:

(note that I'm in the process of testing your changes, so I might be able to answer my own questions along the way ;))

The app I'm currently working on utilizes its own sockets to perform other tasks. For example, it has one TCP socket used to listen/send RPC commands. By using the traditional "FdSet" style socket loop, I simply add my own socket to the FdSet and piggy back on the single set.selectMilliSecond(..) call. Once select returns, I just need to check if my socket was ready and then I perform some actions on it.

This is great because it enables easy integration of custom sockets within the main SipStack reactor loop: it serializes all events in my application, which simplifies it a lot.

If we are to remove the FdSet style loop from reSIProcate I strongly suggest that we keep the ability to use the event loop with other application sockets. I only had a quick glance, but it looks like this might be achievable by using a custom EventStackThread class that would perform application-specific actions on custom sockets.

Cheers,

Francis

 

On Mon, Feb 28, 2011 at 3:37 PM, Kennard White <kennard_white@xxxxxxxxxxxx> wrote:

Hi folks,

There are some new features in resip trunk:

1. The rutil/Random class has some new options to support better random number generation, especially for multi-threaded applications running on multiple core machines. See http://www.resiprocate.org/Random_number_generation for details. That page also includes some interesting performance results. There are (different) improvements available for both Windows and POSIXs. The new Windows support is based upon work by jgeras at ctpc. The default behavior hasn't changed.
2. The callback-based event loop mechanism (that was originally created to provide epoll support) now has a select() based implementation and thus can be used on all platforms. This allows applications to construct the stack in a single style for all platforms, and take advantage of epoll on those platforms that support it. See http://www.resiprocate.org/SipStack_Event_Loop for more information. That page also includes some Linux-based performance results.
3. The POSIX configure script has been extended for both the Random number generation and epoll support. See https://www.resiprocate.org/Configuration_Options for details.
   
4. The rutil/Data class has some new low-level methods for higher performance operation. Most users wont want to use these methods, but they help avoid unneeded copies in certain cases.
5. Fix for contrib/ares (aka resip-ares) to correctly handle IPv6 for certain initialization paths. Credits to ximalaya <ims3g@xxxxxxx> for finding and fixing this one.

Regards,
Kennard

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/