Castecny zapis do socketu
Jan Kasprzak
kas na fi.muni.cz
Pátek Květen 2 21:23:05 CEST 2008
Dalibor Straka wrote:
: Ahoj,
:
: On Fri, May 02, 2008 at 12:03:50AM +0200, Michal Dobes wrote:
: > Jan Kasprzak napsal(a):
: > > Cili zajima me, jak to ze kdyz mi poll()/epoll() rekne ze deskriptor
: > > je pripraveny k zapisu, tak ve skutecnosti se zapis zablokuje? A co mam
: > > delat pro to, aby se nezablokoval?
: >
: > Aby se nezablokoval, tak musí být deskriptor přepnut do neblokujícího
: >
: Neni pravda: (man poll)
: POLLOUT Writing now will not block.
:
: > režimu, jinak bude stát do doby, než zapíše celý udaný bafr.
: >
: write() pripadne vrati mensi pocet zapsanych byte nezli pozadovany.
:
: > Dále (pokud aplikace nemá nárok na přenositelnost kamkoliv) bych si
: > nastavil větší odesílací bafr (SO_SNDBUF) a i přímo nastavil, aby poll
: > a spol hlásil, že deskriptor je připraven na zápis až v okamžiku, kdy
: > tam bude místo na celou strukturu (SO_SNDLOWAT).
: >
: Ale pro uplnou jistotu je dobre pouzit O_NONBLOCK i kvuli nasledujicimu:
:
: Under Linux, select() may report a socket file descriptor as "ready for
: reading", while nevertheless a subsequent read blocks. This could for
: example happen when data has arrived but upon examination has wrong
: checksum and is discarded. There may be other circumstances in which a
: file descriptor is spuriously reported as ready. Thus it may be safer
: to use O_NONBLOCK on sockets that should not block.
:
Tohle se ovsem tyka cteci strany. Ja mam problem se zapisovou.
-Jan Kasprzak
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
>> If you find yourself arguing with Alan Cox, you’re _probably_ wrong. <<
>> --James Morris in "How and Why You Should Become a Kernel Hacker" <<
Další informace o konferenci Linux