by Tom Anderso » Wed, 15 Nov 1995 04:00:00
Also, I had read some time back that there was a group (who didn't want any
new help) that was working on implementing threads ( I beleive it was at the
kernel level, not just a library ) in Linux. Is this available yet?
1. Sockets and threads, sockets and threads
I have an application that I'm writing that has (a) must run over a
network and (b) is expecting a fairly sizable number of simultaneous
connections (500 or so at a time). Connections generally will live for a
long time. What I have in mind is:
1. Recieving data and handling accept() on a separate thread (using
pthreads), which also handles authentication. Recieving locks the
specific socket being read, then unlocks it (using a mutex).
2. Data being sent out comes from a number of other threads, which simply
pull the socket out of a set (std::map<unsigned long, Socket>, actually),
lock it, send, and unlock.
I have a few things I'd like to do. First, a socket that's gone dead
(remote host pulled the network cable or something) can't block the thread
sending while it waits for a send failure. Presumably this means using
non-blocking threads. Second, what's the most sensible way to deal with
that many sockets at once as far as select()-a-like systems goes? Vanilla
select()? Poll? Something more esoteric?
Thanks,
Owen
--
When all else fails, run.
2. Anyone have a CD player program for the RS/6000 CD-ROM drive?
6. Same [Q]: Improving Security....
7. Threads in linux versus threads in NT and threads in Solaris.
9. threads packages: kernel threads vs. user threads
10. POSIX threads, thread-specific data: what about the "main" thread?
11. about thread, signal and socket, oh, difficult to me, hard to debug