Subj : Re: Futexes are wrong! (Are they?)
To   : comp.programming.threads
From : Jomu
Date : Tue Jun 14 2005 01:00 am



David Schwartz wrote:
> "Jomu" <dragisha@gmail.com> wrote in message
> news:1118694635.295293.38720@g49g2000cwa.googlegroups.com...
>
> >>     If you want simplicity, you can use 'poll' with a thread pool. If you
> >> want the highest possible performance, you can use whatever provides the
> >> best performance on your OS.
>
> >  It's so portable... just thinking about it hurts my brain. :)
>
>     The poll function is standardized. It's supported on just about every
> UNIX except Darwin.
>
> >  And so, there goes your: "standard guarantees that", "portability
> > this"?
>
>     If you want the highest performance on any given platform, you must use
> the operation that provides the highest performance. On no platform I know
> of or have heard of is thread-per-connection the highest performance.
> Unfortunately, this means that no matter what, if you want top network
> performance, you must use IOCP on Windows, kqueue on Darwin, epoll on Linux,
> and so on.

  And, of course, I totally agree here... You have varied landscape,
and even that landscape is changing and very fast.

  Major complaint to thread-per-connection is synchronization, and if I
am not mislead there, that is to be changed with wider availability of
lock-free synchronization tools. Even now, cost of running 10,000
threads is (for 64k stack) 640MB VM. It's nothing for x86, and 64bit
platforms would not blink at it. Synchronization is what is tricky
there, but as you say, pool-of-threads is not without it's tricks.

....
> >  But, now you're talking poll()... It was select() to this moment...
> > Stop moving for a moment :).
>
>     I never said "select()" I just used the word select. I am very careful
> to use quotes when I mean a specific function and none when I mean a
> concept. This is absolutely *NOT* about the specifics of any particular
> function.

  But that *IS* a problem. Various systems, various functions. And not
so long ago, you've claimed I can't count on something because it works
for some OS or is specific to some architecture, and you implied some
"big picture" to unseeing me :).

....

>     You can allow the user to select it. You can hard code it. You can make
> it auto-tune. It doesn't matter. Any of these solutions is orders of
> magnitude better than hard-coding it at one.

  And landscape is moving... As disadvantages of t-p-c are disappearing
with past, present and future enhancements to threading and
synchronization, I fully expect you to re-tune.

  For me... I will use pool-of-threads for I/O handling and threads for
client handling, with queues in-beetween. As I am not implementing new
Apache, I am sure it will suffice, and working version of my software
will show how well it fits. As I finish it, I know there would be new
hardware and new software available, and I know my software will work
better than it would work if available today. Moving landscape, as I
say.

> 
>     DS

  dd

.