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