[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Thread implementations...
Gerard Roudier writes:
> On Tue, 23 Jun 1998, Richard Gooch wrote:
> > Well, I'm not one to jump to using threads just for the hell of
> > it. Why not read the proposal carefully before jumping up and saying a
> > threads-based solution is flawed? See:
> >
> I did read your proposal. As answer, here is the description of an
> application program I wrote 5 years ago and that is always alive
> nowadays.
> - Completely even driven.
> - Use SIGIO under UNIX.
> - Use non-blocking mode under UNIX.
> - Use select and perform select for write only for socket on which send
> returned EWOULDBLOCK on UNIX.
> - Implement both the client side and the server side of a sophisticated
> protocol.
> - 1 process is able to handle severall hundreds connections at the same
> time, client and server as well.
> - Nominal load 100 to 200 simultaneous connections.

So when you want to know that a connection has fresh incoming data,
you get SIGIO when the event comes? Now how do you know *which* FD
received new data? AFAIK the signal handler has no knowledge of which
FD had the I/O completed. It looks to me you are then forced to
attempt a read on *every* FD.

How on earth does this scale with large numbers of FDs?

> Use threads for this kind of applications and you break portability and
> probably performances at the same time.

do it with threads and get good scalability ();
do it with poll(2) and hope for the best

Performance: unless you have some secret way of finding out *which* FD
received data, your scheme is far slower than a simple poll(2)
implementation. And I think that my threads-based approach will work
well. I'll be publishing numbers too.

> Using 1 process with bunches of threads is the common way to develop
> optimized application for NT. Doing so, you run the risk to break
> performances and portability to other O/Ses.
> My experience is that a well designed application can be ported to
> NT/95 and often OS2 and that applications that have been developed
> for these crap platforms are about not portable to other platforms.
> Having nice thread implementation on UNIX in order to use them
> intelligently is OK. But if the goal is to follow Microsoft
> dictatorship in order to facilitate port of NT applications
> to UNIX, them my feeling is that we are just ripped off.

No, I'm proposing a pure-UNIX solution for UNIX systems, for maximum
portability. On a system without thread support, you fall back to
simple poll(2) because that's all you can do.

> Your proposal is to divide the whole FD list to select()/poll()
> into severall ones, each handled by 1 thread.

Yes. Just two threads. One for the active list and the other for the
inactive list.

> You are exchanging CPU load due to FDs list scan for context-switching.
> This can be an interesting optimization for some specific
> applications. For some other, this probably will make no
> differences or perhaps have adverse effects, in my opinion.

I don't think there will be that much context switching going on that
it becomes an overhead. Anyway, we'll see.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:43    [W:0.082 / U:10.876 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site