Re: Best practice for accepting TCP connections on multicore?

On 7 June 2014 14:38, Igor Mozolevsky <igor@hybrid-lab.co.uk> wrote:
>
>
>
> On 7 June 2014 17:42, Ian Lepore <ian@freebsd.org> wrote:
>>
>> On Sat, 2014-06-07 at 12:06 -0400, Adrian Chadd wrote:
>> > On 7 June 2014 10:19, Igor Mozolevsky <igor@hybrid-lab.co.uk> wrote:
>> > > On 7 June 2014 01:53, Dirk Engling <erdgeist@erdgeist.org> wrote:
>> > >
>> > >>
>> > >> On Sat, 7 Jun 2014, Daniel Janzon wrote:
>> > >>
>> > >>  Is there any better way than doing the accept() call in one thread
>> > >> and
>> > >>> then
>> > >>> dispatch it to a thread on another core with any user space method?
>> > >>>
>> > >>
>> > > See C10K problem [1].
>> > >
>> > >
>> > > Why use accept() and not kevent()? You need to keep it portable?
>> > >>
>> > >
>> > > Has anyone rebutted the threads better than events paper[2] yet?
>> > >
>> > >
>> > >
>> > > 1. http://www.kegel.com/c10k.html
>> > >
>> > > 2.
>> > >
>> > > https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf
>> >
>> > Not likely; but that paper talks about a threading model that isn't
>> > currently in use in popular UNIX operating systems. It also compares a
>> > lightweight thread implementation with a lightweight server to an
>> > event driven system with worker threads that acted pretty badly,
>> > causing extremely bad memory use and context switching.
>> >
>> > We've all gotten better at programming since then.
>>
>> Yeah, when I glanced at the link and saw it was a cite of a 2003 paper,
>> my gut reaction was "Yeah, it has been rebutted by 11 years of everyone
>> just getting on with their lives and evolving absolutely everything that
>> was tested into something completely different now."
>
>
> I can't possibly argue with that sort of scientific method, but back in
> 2008, someone did some stuff with Java and got interesting results[1].
>
>
> 1. http://www.mailinator.com/tymaPaulMultithreaded.pdf
>

It's Java, and its design also pulled in bits from the Java way you do IO.

I think we can do better.

-a
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"