[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
[an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]![]() |
![]() |
![]() |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
![]() |
![]() |
![]() |
Peter Maersk-Moller wrote: > Hej Robert > > Jeg regner med at have typisk et par hundrede (max 2 til firetusinde) > sockets åbne for læsning og skrivning samtidig. > > Der er forskellige metoder og nogle af dem er beskrevet her > > http://bulk.fefe.de/scalable-networking.pdf > > En tråd per read() er nok den nemmeste måde at gøre det på, men da > skal read()-write() helst være blocking af performancehensyn og for > nem scheduling. > > Men måske er jeg tvunget til at bruge select(), skønt der vist er > nogle skaleringsproblemer i at bruge select på et par tusinde sockets > samtidig. Med så mange ville jeg bruge epoll(). Det gør ca. det samme som select() men meget mere effektivt. > > Men selv select() er blokeret .. men der er vist en timer på. Så måske > ved brug af select(), behøver jeg ikke at bruge KillThread. Både select() og epoll() kan times ud (sidste parameter på select() og epoll_wait()). > > Men hvad sker der ved at bruge KillThread på en tråd, der er i > wait-block på read eller write ? Den stoppes uden at få en chance for at rydde op efter sig. > > Er der noget med at man kan bruge signal() til at få en blokeret read > til returnere ... bare uden at der er læst noget og med errno sat ? > Vist nok til EAGAIN. Hmm man siger vist noget andet, men maaske kunne > den sætte EINTR ? Ville det være en ide, at låse op for blocking read > med signal og få dem til at returnerer-exit'te selv ? Får det alle blokerede kald til at returnere ? For så ville det jo kunne virke. > > Hmm, hvordan er det lige man læser errno, når man har et par tusinde > blokerede reads eller writes ? errno er jo en fælles variabel for alle > io-operationer. Jep. errno er fra før multithreading tiden, så den er lidt farlig at stole på. > > Hvis SIGALRM er brugt til at få read() til at returnere med errno sat > til EINTR, rejser det et par issues > > a) Er der kun en read(), der returnerer med errno sat til EINTR per > SIGALRM eller er det alle måske flere tusinde read(), der returnerer ? > > b) Hvis read() returnerer -1 med errno sat til EINTR når jeg > genererer SIGALRM, hvordan sikre man sig, at man kan læse errno inden > en anden tråds I/O ændrer værdien i errno ? > Race conditions er dejlige :-) Jeg tror, at den "nemmeste" løsning vil være at bruge select()/epoll(). Bare lige en advarsel, jeg prøvede engang at bruge mere end 1024 filedescriptors i select() og fik det aldrig til at virke. Det virkede heller ikke at redefinere FD_SETSIZE, som man ellers kan gøre i andre operativ systemer, så jeg er stort set gået over til udelukkende at bruge epoll(), medmindre jeg skal bruge select()'s portabilitet.
![]() |
![]() |
![]() |
||||||||||||
|
||||||||||||||
![]() | ||||||||||||||
|
||||||||||||||
![]() |
![]() |
![]() |