Dan Lukes napsal(a):
> No, proc tam nabidnuty patch neni tam je vysvetleno - tato cast kodu se
vola i v kontextech kdy pouziti zamku (a tedy serializace jak jsem ji
popsal vcera) neni bezpecne pouzitelna.
To je sice hezke, ale pokud nekde neco dela nesmysly, bylo by dobre, aby
na to nekdo sedl a vymyslel to tak, aby to nesmysly nedelalo (vim, to my
tady nevyresime...). Sic se nam linuxaci zase budou smat, protoze oni
urcite tak hloupy problem nemaji.
Ten, kdo PR uzavrel si mysli, ze resenim je pouzit
options PRINTF_BUFR_SIZE=N
Pak, kdyz dojde k prokladani, tak nebude prokladano po jednom znaku, ale
po N. Reklo by se - staci vzit dostatecne velke 'N' a je v podstate
vyreseno. Ano, jenze ten buffer se alokuje na zasobniku a v kernelu uz
neni, rekneme, 128 byte (coz je hodnota, ktera se pro N obcas
doporucuje), zanedbatelne mala pamet. Tam se porad jeste hraje o
jednotlive byte (no, rekneme desitky byte).
Jak velke to N je ted (kde to zjistim)? Co se stane, kdyz to s velikosti
N prezenu? Existuje nejaky zpusob, kterak odhadnout ono N tak, aby to
clovek nemusel zkouset zvedat po jednom a v urcitem okamziku pri onom
zvyseni o jedna nedoslo k pruseru?
Zbynek
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
