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