[Asterisk-Dev] rewriting asterisk as a state machine?

[Kevin Lindsay]

I would argue that a proper state machine implementation would be more
efficient at handling large call volumes. After all, computers are state
machines themselves. 

There are methods other than select() and poll(), as poll() doesn't scale
very well either. epoll() has been implmemented in kernel 2.6, but its
not portable. I believe this is the reason libevent was created.

This is an older document but it has some good reading on the subject:
http://www.kegel.com/c10k.html

There is also state-threads:
http://state-threads.sourceforge.net/

However it still uses select()/poll()... :-/

Kevin-

On Thu, Mar 03, 2005 at 03:12:48PM -0500, Steve Kann wrote:

> [Continuing the top-post, hoping it's the least-annoying choice to make]:
> 
> This all assumes that a select() based implementation would be faster 
> than a threaded implementation. That's not necessarily clear.
> 
> First of all, for select() you lose, because it doesn't scale, so you 
> need poll().
> 
> Second, while 5 years ago, it would definitely have been true, thread 
> performance on all platforms has improved considerably, and I wouldn't 
> be surprised if it's not faster than an equivalent IO-driven model.
> 
> Anyway, RoyK, why don't you try doing it, and let us know how the 
> performance compares.
> 
> -SteveK
> 
> 
> Nir Simionovich wrote:
> 
> >Alex,
> >
> > I would have to disagree with you on that one. Although CPU's are getting
> >cheaper from day to day, that is not the way to go. 
> >
> > The approach you are taking is: It's too slow, no problem, lets ramp up
> >the minimum requirements. 
> >
> > That kind of approach brought us products like Windows, where no matter
> >what kind of power you have, it never works right. Now, lowering the number
> >of CX's on the core would mean that the software density is improved
> >dramatically, in addition to improving stability and reliability. Think of
> >it this way, 3500 CX's means 3500 possible error locations, reduce that to
> >50 or a 100, you do the math. 
> >
> > I must admit that it had been a while since I've written a multi-threaded
> >code in C/C++ (man I'm rusty), but the advantage is clear as the sun. For
> >Asterisk to become bigger than life - parts of the switching core should be
> >either optimized or completely re-written from scratch.
> >
> >JMHO
> >
> >Nir S
> >
> >-----Original Message-----
> >From: asterisk-dev-bounces at lists.digium.com
> >[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of
> >alex at pilosoft.com
> >Sent: Thursday, March 03, 2005 9:17 PM
> >To: Asterisk Developers Mailing List
> >Subject: Re: [Asterisk-Dev] rewriting asterisk as a state machine?
> >
> >On Thu, 3 Mar 2005, Roy Sigurd Karlsbakk wrote:
> >
> > 
> >
> >>in current asterisk gateway setups, a set of 20 active channels
> >>generates something like 3500 context switches per second, giving a
> >>170-200 context switches per channel per second. This is an awful lot...
> >>   
> >>
> >It is an awful lot. But realistically, it should be at least 50 ctx 
> >switches per channel per second (reading 20ms samples). 
> >
> > 
> >
> >>Would it be possible to rewrite asterisk so as each channel's data
> >>read/write would be in common threads with a select() or so? what would
> >>this take? this really would decrease the overhead on busy systems....
> >>   
> >>
> >That would be a heavy rewrite, changing blocking code with threads into 
> >nonblocking code with select() - is untrivial task, and probably 
> >pointless.
> >
> >CPU are cheap.
> >
> >-alex
> >
> >_______________________________________________
> >Asterisk-Dev mailing list
> >Asterisk-Dev at lists.digium.com
> >http://lists.digium.com/mailman/listinfo/asterisk-dev
> >To UNSUBSCRIBE or update options visit:
> >  http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> >_______________________________________________
> >Asterisk-Dev mailing list
> >Asterisk-Dev at lists.digium.com
> >http://lists.digium.com/mailman/listinfo/asterisk-dev
> >To UNSUBSCRIBE or update options visit:
> >  http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> > 
> >
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
Kevin-