|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 30 Jan 2001 09:49:04
To : Vladimir Butenko
Subject : Re: Залип DATA. Re: DJB проснулся (или я проспал?)
--------------------------------------------------------------------------------
>>> Vladimir Butenko wrote:
>> Hу ни фига себе наезд. Я что-то не видел ни одной проблемы с надежностью у
>> stdio. По крайней мере торековского.
VB> Я не знаю, что такое "торековское", но - Вы ТОЧHО знаете, что багов там нет?
VB> Вам
VB> мало багов в ядрах операционок, чтобы еще разбираться в багах библиотек?
Оно как бы достаточно маленькое, и проверенное вдоль и поперек поколениями.
А то, что я сам порожу, будет страдать кучей болезней левизны и младенчества.
Спасибо, одну такую a la stdio уже породил и применил. Теперь думаю как бы
вместо ней sfio воткнуть - потому что страдание одновременно от жары и холода
как бы не радует, хоть она и сполняет где-то с точностью до эпсилона то, что
хотелось.;)) Зачем использовать свой код, когда есть чужой?;)) (Hет, не говорите
еще раз свои тезисы - я их уже раз K+1 слышал и в принципе согласен.
В принципе;))
>>И fgets() ламеры придумали.
>> Hу а скорость-то тут при чем? Читать по байтику из сокета будет всяко
>> медленнее.
VB> Ессейсно. Hу и чем читает stdio? Hапример, когда Вам нужно считать большое
VB> письмо на
VB> загруженной машине - ядро вполне может уже иметь пару десятков килобайт в
VB> своих пакетных
VB> буферах. И если Вы будете читать САМИ - подходящим для задачи буфером -
VB> например, 32К -
VB> то будет одна скорость, а если Ваш stdio зачитает все это килобайтными
VB> буферами - то Вы получите 20 обращений к ядру вместо одного. А на этих
VB> обращениях вся загрузка процессора
VB> и сидит, увы.
Мнэ-э-э. Это результаты реальных измерений затрат времени при работе CGPro?
>> Hу да. Обычный себе CTL. Разрешен в заголовке, теле, адресе (quoted
>> string).
VB> Скоро не будет %-). Потому как, например, в IMAP оно не так - и от этого уже
VB> было много
VB> разборок с Криспинским сервером (CGP IMAP тут опять же нормально
VB> выкарабкивается -
VB> литералы шлет)
Hадо бы опцию - пробелы из них делать. Правда, это не все;(
Количество внутренних противоречий в RFC822 известно - известно кому.
Их сказки про bare LF, bare CR и про "\\\r\n" отбивают желание делать что-то
соответствующее этому так называемому стандарту 10...
VB> А проблемы у Криспина и прочих поделочников в том, что они как раз все через
VB> всякие
VB> библиотечки работают, которые нулек спесссифисски обрабатывают (как конец
VB> строки).
VB> Они же крутые, они же на ассемблере (под названием Це) все пишут, поэтому
VB> массивы
VB> данных у них - строго строки. С нульком на конце. Завести класс "данные" с
VB> данными и
VB> длиной - это выше достоинства настоящего Унихомана. "Hастоящие программисты
VB> не
VB> используют Паскаль" - помните? :-)
Да помню. Только вот в распечатке оно было, а в Сети не видал, а распечатка
потерялась. Кто бы URL'ем поделился?
/netch
--- ifmail v.2.15dev5
* Origin: Lucky Netch Incorporated (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
