Hi! > Sure. Make each thread call accept and let the kernel give incoming > sockets to one of them. There you have the listener done :) > Solaris used to need an explicit locking, but it is now fixed there, too.
Heh, I somewhat ignored this way - yeah, it would work just fine - one can do per-file synchronization rather than per-event, as there's not much state involved on either side. > Given the following incomint events: > udp2log has problems > jeluf created a new wiki > domas fixed the server > > I call corrupted this: > jeluf domas > udp2log has fixed the server > problems created a new wiki Well, you wouldn't want to use fwrite/etc calls, as their behavior in threaded environment isn't that useful :) write()s aren't atomic either, so... what you have to do is: lock(fd); write(); write(); write(); (may be needed for single buffer, in case first write is not complete) unlock(fd); > I don't get it. What is slow on it? > > What it does is: > 1) Get socket data > 2) Split line into pieces > 3) fwrite each line in 16 fds > 4) Go to 1 1) Get socket data 2) Split packet into lines 3) Write lines into 16 fds 4) Go to 1 > If there's plenty of CPU, the pipes doesn't fill, the fwrite doesn't > block... > Why isn't it coping with it? > Too much time lost in context changes? There're no context changes, as it running fully on a core. "plenty of CPU" is 100% core use, most of time is spent in write(), and apparently syscalls aren't free. Domas _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
