Messages in this thread | | | Date | Wed, 24 Jun 1998 10:11:55 +1000 | From | Richard Gooch <> | Subject | Re: 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: > > http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html > > 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.
Portability: #ifdef _POSIX_THREADS do it with threads and get good scalability (); #else do it with poll(2) and hope for the best #endif
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.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |