> 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.
Portability:
- 100 to 500 lines of platform specific code per target.
(Only OS2 port made problems for well known reasons)
TLI as been one of the target, TANDEM/GUARDIAN too, NT of course,
and some others.
(BTW, it is not an X server)
When this thing looping to himself, it is able to consume 100 % of CPU
with a low number of context switching.
On SMP, we can create as much instances of this process as we have CPUs.
Use threads for this kind of applications and you break portability and
probably performances at the same time.
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.
Your proposal is to divide the whole FD list to select()/poll()
into severall ones, each handled by 1 thread.
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.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu