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

Kennard White kennard_white at logitech.com
Tue Mar 1 11:11:18 CST 2011


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 at gmail.com>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 at logitech.com
> > 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 at 126.com> for
>>    finding and fixing this one.
>>
>> Regards,
>> Kennard
>>
>> _______________________________________________
>> resiprocate-users mailing list
>> resiprocate-users at resiprocate.org
>> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20110301/27b2565e/attachment.htm>


More information about the resiprocate-devel mailing list