пятница, 13 марта 2009 г.

Вот так эволюционировал GUI

Интересная статья с подборкой скриншотов об истории эволюции GUI на персональных компьютерах.

Меня всякие рюшечки в виде полупрозрачных иконок и обилия цветовых переходов не интересуют. Да, сначала смотришь на новый интерфейс, иногда даже говоришь “Вау!”. Но буквально через несколько дней перестаешь обращать на оформительские изыски внимания. Поэтому для каждодневной работы для меня нет большой разницы между:

и

Первый даже удобнее (я о KDE 3), поскольку в нем есть одна маленькая, но очень важная фишечка: реализация полос прокрутки. Можно увидеть, что внизу вертикальной полосы прокрутки расположены сразу две кнопочки: вверх и вниз. Что делает очень удобным мелкий скроллинг на строку вверх/вниз. Ведь не приходится перемещать курсор мыши вверх окна. В Windows с этим хуже.

Вот так и оказывается, что не оформление главное, а структура интерфейса (если я правильно выразился).

А вообще лично мне больше всего нравился интерфейс Windows NT 3.51 (которая была до NT 4). Отличная была система: надежная, не требовательная (на 486DX2-80 с 16Mb работала так же здорово, как и OS/2 Warp), простой и удобный интерфейс из Windows 3.*…

Что-то старею я, в ностальгию потянуло…

PS. Готовя этот пост наткнулся на интересный сайтик: http://www.guidebookgallery.org
Откуда и стащил картинку WinNT 3.51.

четверг, 12 марта 2009 г.

Похоже, что SObjectizer 4.4.0 будет поддерживать только TCP/IP

Приступил к разработке седьмой бета-версии SObjectizer 4.4.0. С таким прицелом, чтобы сделать ее сразу релиз-кандидатом. И, если по прошествии трех-четырех месяцев активной эксплуатации не будет выявлено серьезных проблем – объявить ее финальной версией 4.4.0.

Одна из целей beta7 – поддержка еще одного вида транспорта в SObjectizer. Хотел реализовать взаимодействие SObjectizer-процессов через разделяемую память. Благо, видел в ACE средства для ее поддержки. Но не тут-то было. Маленький пушной зверек, как водится, подкрался незаметно.

В ACE действительно есть средства для работы с разделяемой памятью. Низкоуровневые и высокоуровневые. Высокоуровневые (т.к. ACE_MEM_Stream, ACE_MEM_Connector, ACE_MEM_Acceptor) реализованы так, чтобы вписываться в стандартную ACE-овскую архитектуру реакторов. И, поскольку в SObjectizer 4.4 транспортный слой как раз ориентирован на ректоры и Event_Handler-ы, то я решил воспользоваться именно высокоуровневыми средствами.

Разобраться с механизмом работы ACE_MEM_* классов оказалось не просто. Т.к. никакой внятной документации по ним нет, за исключением небольших Doxygen-комментариев. Так что пришлось лазить прямо по исходникам. Здесь в очередной раз хочется сказать, что OpenSource это есть очень хорошо и правильно. При наличии исходников можно понять все. Тем более, что качество кода в ACE довольно паршивенькое, но благо без мозгодробительных трех-этажно-шаблонных конструкций. Разобраться что к чему удалось. И вот, что выяснилось…

Оказывается, у ACE реализован свой транспорт на основе разделяемой памяти. Транспорт этот может быть двух видов: с передачей уведомлений через TCP/IP сокет (режим ACE_MEM_IO::Reactive) или через примитивы синхронизации (режим ACE_MEM_IO::MT). Но в любом случае для канала на основе разделяемой памяти требуется TCP/IP сокет. Насколько я понял, как вся эта кухня работает так:

1. Серверная сторона создает серверный TCP/IP сокет и ожидает подключение клиентов. Когда клиент подключается, серверная сторона через TCP/IP сокет договаривается с клиентом о способе коммуникации (Reactive или MT). После чего создается отображаемый в память файл и имя этого файла передается через тот же сокет клиенту. Клиент получает это имя и открывает данный файл.

2a. Если работа идет в режиме ACE_MEM_IO::Reactive, то о каждой операции записи в разделяемую память делается нотификация удаленной стороны через запись уведомления в TCP/IP сокет. Т.е., при записи в ACE_MEM_Stream данные копируются в разделяемую память, а уведомление о них пишется в сокет.

2b. Если работа идет в режиме ACE_MEM_IO::MT, то используются примитивы синхронизации ОС (вроде бы semaphore и condition variable) для уведомления удаленной стороны. Т.е., при записи в ACE_MEM_Stream данные копируются в разделяемую память и взводится condition variable. Если удаленная сторона спала на этом condition variable, то она проснется.

Подлость в том, что в режиме ACE_MEM_IO::Reactive можно повесить ACE_MEM_Stream на реактор. И реактор будет уведомлять о поступлении данных. Т.е. поддерживается та схема работы, на которую был ориентирован транспортный слой в SObjectizer 4.4.0. Но при этом скорость работы через разделяемую память оказывается (на мелких порциях данных) даже ниже, чем при работе через сокеты. А если взять режим ACE_MEM_IO::MT, то для получения входящих данных нужно висеть на recv() постоянно. Т.е. нужно выделять отдельную нить, которая будет читать входящие данные. А потом еще и управлять этой нитью как-то. Причем хотелось бы, чтобы данная нить могла прослушивать сразу несколько каналов (как это происходит в ACE_Select_Reactor-е с сокетами). И если под Windows еще можно было бы что-то придумать с WaitForMultipleObjects (или ACE_WFMO_Reactor), то что делать под Unix-ами я не очень представляю.

В общем, с этим всем можно было бы бороться, если бы не глюк в ACE, на который мне довелось наткнуться (видно карма у меня плохая, слишком часто глюки в ACE мне попадаются). Глюк сам по себе заслуживающий внимания. Поскольку я даже не придумал, как его исправить и, поэтому, не решил, имеет ли смысл о нем вообще в ace-bugs писать.

Итак, в документации к ACE сказано, что ACE_MEM_Stream за один раз не может передавать больше, чем было первоначально выделено разделяемой памяти. Ну не может, так не может. Но что будет, если попробовать это сделать? Операция recv() возвращает, как положено, –1. А затем программа аварийно завершается. Выяснилось, что деструктор ACE_MEM_Stream пытается записать что-то в канал. Попытка записи приводит к обращению по некорректному указателю. Но откуда этот указатель берется?

Выяснилось, что при попытке записи в память ACE_MEM_Stream просит у подчиненного объекта ACE_Malloc_T подходящий блок. Подходящего блока не находится и в методе ACE_Malloc_T::shared_malloc() выполняется код:

          else if (currp == this->cb_ptr_->freep_)
            {
              // We've wrapped around freelist without finding a
              // block.  Therefore, we need to ask the memory pool for
              // a new chunk of bytes.

              size_t chunk_bytes = 0;

              currp = (MALLOC_HEADER *)
                this->memory_pool_.acquire (nunits * sizeof (MALLOC_HEADER),
                                            chunk_bytes);
              void *remap_addr = this->memory_pool_.base_addr ();
              if (remap_addr != 0)
                this->cb_ptr_ = (ACE_CB *) remap_addr;

Управление попадает в ACE_MMAP_Memory_Pool::acquire(), оттуда в ACE_MMAP_Memory_Pool::map_file(). И одним из первых действий в map_file оказывается:

  // Unmap the existing mapping.
  this->mmap_.unmap ();

т.е. происходит отмена отображения части файла в адресное пространство процесса (соответственно, все адреса, которые были определены в данном отображении, становятся “повисшими”). Нужно это, по-видимому, для того, чтобы затем отобразить в адресное пространство кусок файла большего размера. Но эта попытка завершается неудачно. И, в результате, ACE_MMAP_Memory_Pool::acquire возвращает 0.

Однако, самое важно то, что в ACE_Malloc_T атрибут cb_ptr_ указывает как раз на отображенный в адресное пространство процесса фрагмент файла. Но данного фрагмента уже нет, т.к. было выполнено обращение к unmap()! Т.е. после возврата из acquire() значение this->cb_ptr_ уже содержит мусор!

Похоже, что разработчики ACE расчитывали на то, что после acquire() значение cb_ptr_ станет некорректным. Именно поэтому в коде ACE_Malloc_T::shared_malloc() стоит проверочный код:

              void *remap_addr = this->memory_pool_.base_addr ();
              if (remap_addr != 0)
                this->cb_ptr_ = (ACE_CB *) remap_addr;

Но этот код рассчитан на то, что remap_addr не будет нулевым. Т.е., что map_file() не завершается неудачно. А тут завершается. В результате в this->cp_ptr_ так и остается мусор. И на этот мусор мы натыкаемся, когда деструктор ACE_MEM_Stream пытается что-то записать в канал. Как вполне естественное следствие – крах приложения.

Вот такие вот пироги. Я лично убежден, что раз уж recv() возвращает –1, то ничего больше в программе ломаться не должно. Но в случае с ACE это не так.

По сумме всех вышеизложенных факторов я решил не делать в седьмой бете поддержку транспорта на основе разделяемой памяти. Поскольку высокоуровневый механизм ACE для разделяемой памяти оказался медленным (в случае ACE_MEM_IO::Reactive) или неудобным в использовании (в случае ACE_MEM_IO::MT), да еще и глючным. А делать какой-то свой механизм с нуля не очень хочется. Жалко времени, честно говоря. Есть еще важные вещи, которые хотелось бы включить в SObjectizer 4.4.0 и освободить время и ресурсы на разработку SObjectizer-5.

Такие дела. Так что останется SObjectizer 4.4.0 только с TCP/IP транспортом. По крайней мере пока не возникнет очень настоятельной необходимости в поддержке чего-то другого.

понедельник, 9 марта 2009 г.

Об интуитивности императивного и функционального программирования

Данная тема навеяна очередным RSDN-новским флеймом по поводу функционального программирования (ФП). Толчком стало утверждение, что в 1980-е годы объектно-ориентированное программирование (ООП) с трудом завоевывало себе место под солнцем. Не знаю, что происходило на Западе в 1980-е, но в 1992-м я уже программировал на C++ с объектами, даже не подозревая, что использую ООП. Об этом я узнал несколько позже, наверное, в 1994-м. Тогда же, может чуть раньше, я стал понимать, что переход к ООП действительно требует некоторого изменения способа мышления. Но у меня самого это изменение прошло незаметно и безболезненно. Чего не происходит по отношению к ФП. Почему же?

Начинать нужно с того, что наш мир изменяем (т.е. мутабелен). Это дано нам в ощущениях с самого детства. Например, нельзя просто так нарисовать линию карандашом на бумаге, потом бесследно убрать ее и нарисовать вновь. Ластик неизбежно оставляет следы, поэтому даже если очень аккуратно стереть первую линию, вторая все равно будет выглядеть уже несколько иначе.

Более того, воспитание человека идет в том ключе, что любое его действие неизбежно ведет к последствиям. Поэтому наши действия должны быть продуманы и взвешены. Чтобы не было мучительно больно и т.д.

Со временем человек учится воздействовать на окружающий мир не только через действия, но и через указания. Начиная с детских требования “хочу конфету”, заканчивая управлением подчиненными в зрелом возрасте. Мы понимаем, что нужно отдавать команды, которые будут приводить к результату. Команды должны быть упорядочены и осмысленны, а это уже программирование. И, что еще важно, команды используются чтобы изменять окружающий нас мир.

Так же в реальной жизни мы встречаемся с модульностью и структурным подходом. Еще в детском саду мы узнаем, что в группе самая главная - воспитательница, но она не самая главная в саду, есть еще и заведующая. Потом мы видим иерархии в школе, в спорте, в армии, на производстве…

Итак, все наше существование показывает нам, что мир вокруг изменяем и, местами, структурирован.

Когда начинается процесс обучения программированию, мы видим то же самое. Первые программы, которые я писал в школе, были предназначены для того, чтобы производить видимые изменения - рисунки на экране. Было здорово - я давал команды компьютеру, чтобы он изменил пиксели на экране. Я видел вносимые мной в мир изменения. И, наверное, именно так я заразился программированием: с помощью чего-то эфемерного (ведь программу нельзя пощупать) я достигал видимого результата.

Да и само объяснение принципов работы компьютеров, услышанное когда-то в школе, вполне согласовывалось с обычным ощущением изменяемости нашего мира. Мол, есть память, состоящая из ячеек. Есть процессор, есть текущая позиция в памяти. Процессор берет значение из ячейки, текущая позиция сдвигается... И т.д., и т.п. Как-то без проблем стало понятно, почему память конечна, и почему целое число может содержать значения только в каком-то диапазоне. Реальный мир, ничего с ним не поделаешь.

Уже в университете, нам объяснили, что программы бывают не просто большие. А очень-очень большие. Настолько большие, что сам их размер представляет серьезную проблему. И поэтому люди используют по отношениям к программам те же самые приемы, что и по отношению к самим себе - разделяют, властвуют и стараются не выносить сор из избы. Т.е. делят программы на модули и прячут грязное белье этого модуля в нем самом.

Благо, в университете вначале обучение велось на Turbo Pascal, в котором модули были на уровне языка (помнится, они были слизаны с Modula-2). Поэтому вхождение в структурное и модульное программирование произошло быстро и незаметно.

Затем я переключился на C. Хотя сам C мне не нравился. После Turbo Pascal он был какой-то сильно замороченный, да и компилировался на порядки дольше. А осенью 1991-го я раздобыл у знакомого книгу “Язык программирования C++” (первое издание) в электронном виде. По ходу ее первого чтения я даже не отдавал себе отчета о том, что это не C, а другой язык (вероятно, я просто не распечатал “Введение” из книги). На полном серьезе: я полагал, что книга описывает просто новую версию языка C. Поэтому был очень удивлен, когда Turbo C 2.0 оказывался компилировать мои программы с оператором new :)

Так вот, о переходе к ООП. После Паскаля в C мне очень не хватало такой простой и нужной вещи, как множества. В Паскале можно было объявить, например, множество символов и проверять, есть ли там какой-то символ. В C множеств не было, что вызывало у меня жуткий дискомфорт. Зато в Паскале нельзя было написать собственную функцию, получающую переменное число аргументов. Стандартные Write и WriteLn могут получать разное количество аргументов, а мои собственные функции - нет. Т.е. Паскаль не позволял программисту достигать того, что могли сделать разработчики компилятора Паскаль. А в книге я читаю, как в C++ средствами самого языка можно организовать множество. И что это множество будет вести себя точно так же, как и “зашитые” в язык вещи (вроде int). Вот тут-то я и попался на крючок C++. Этот язык давал пользователям языка те же возможности, что и своим создателям.

Само понятие класса в C++ для меня стало аналогом понятия unit из Turbo Pascal. В общем, такое же средство обеспечения модульности, только чуть в других масштабах и с несколько другими возможностями. Кстати, до сих пор очень жалко, что в C++ нет таких модулей, как в Turbo Pascal :(

Итак, сам того не подозревая, я стал последователем ООП, но исходя, первоначально, из соображений модульности. Если мне нужно было какое-то понятие в программе, которое имело собственные внутренние данные, то это понятие оформлялось в виде класса с закрытыми/защищенными атрибутами и публичными методами. Потом уже дело как-то дошло и до виртуальных методов, и до переопределения поведения в классах-наследниках, и до интерфейсов, и всего прочего. В конце-концов, до понимания того факта, что я использую именно ООП.

Таким образом, я на собственном опыте убедился, что ООП - это вполне естественная и интуитивно понятная концепция. И что при обучении императивному программированию (т.е. изменению состояния программы через прямые команды) и ООП мы на каждом шагу видим совпадения с тем, что происходит в реальном мире. Именно поэтому обучение императивному программированию идет настолько просто.

В отличие от функционального программирования, которое строится на абстракциях. А абстракции, это такая хитрая штука… Абстракции на то и абстракции, что их сложно объяснить на пальцах, на примерах того, что можно увидеть за окном. В моем случае, проблемы с математикой начались с возникновения в школьной программе пределов, дифференциалов и интегралов. Предел - это абстракция. Для меня предел - это пустой звук. Я не могу себе представить предел ни в виде какого-то предмета, ни в виде рисунка. Поскольку я не могу понять, что это, то я не могу представить себе ни зачем он нужен, ни как его использовать. Выучить вид пределов и операции над ними можно. Но понимания-то нет. А значит, нет и использования.

Так вот, возвращаясь к ФП. Программа, состоящая из функций. А функции не производят побочных эффектов. Мы запускаем функцию несколько раз и получаем один и тот же эффект. Поскольку вокруг ничего не менялось. Т.е. мы нарисовали линию на бумаге. Стерли ее. И нарисовали линию еще раз. Точно такую же. Абсолютно точно такую же. Но ведь это же противоречит тому, что мы познавали в различных проявлениях с самого детства - любое действие изменяет мир вокруг нас. Итак, первое противоречие с практическим опытом: функция - это абстракция, которую сложно объяснить на пальцах.

Далее, программа состоит из функций, которые не производят побочных эффектов. Но в чем смысл таких программ? Программы пишутся для того, чтобы они выдавали результат, т.е. создавали побочные эффекты. Вывод результата на экран - это побочный эффект, ведь содержимое экрана меняется. Второе противоречие: смысл и назначение программы в создании побочных эффектов, но в процессе ее написания мы преследуем другую цель - устранение побочных эффектов.

Более того, поскольку второе противоречие существует объективно, в программах на функциональных языках нужно как-то выделять фрагменты, которые отвечают за производство побочных эффектов. И тут на арену выходят монады. Еще одна абстракция, которую не объяснишь на пальцах…

Что ж, пора закругляться.

Императивное программирование настолько хорошо воспринимается людьми потому, что его принципы согласуется с тем, что человек наблюдает вокруг себя. ООП для меня интуитивно и понятно, поскольку я воспринимал его как продолжение структурности и модульности. А структурность и модульность – естественное следствие борьбы с размером и сложностью.

Функциональное программирование не интуитивно, поскольку его принципы противоречат наблюдаемой мной изменчивости мира. ФП не очень понятно, поскольку оно базируется на абстракциях.

Собственно, в разгорающемся сейчас интересе к ФП меня больше всего волнует вопрос о том, компенсирует ли ФП затраты, понесенные на его изучение и применение. Ответа у меня нет, но есть весьма скептическое отношение к ФП.

Но и яро отрицать ФП я пока не берусь. Поскольку вспоминается аналогия из легкой атлетики. За время существования прыжков в высоту, техника прыжка серьезно менялась два раза. И нынешний прыжок-прогибом, с помощью которого были поставлены современные рекорды, очень далек от интуитивности и очевидности. Может быть, ФП и есть тот самый прыжок-прогибом? Хотя, если продолжать данную аналогию, то более вероятно, что программирование - это вся легкая атлетика, а прыжки в высоту всего лишь одна из ниш в программировании. И ФП будет ставить свои рекорды именно в этой нише.