Статья Qt vs Gtk... + вопросы...

не знаю. всё зависит от того что петроша собирается писать. думаю ему видней.

>не знаю. всё зависит от того что петроша собирается писать. думаю ему видней.

угу, читаю сегодня целый день и про то и про другое их собственные доки. Я бы сказал, что с точки зрения начинающего, разницы не очень много. И там и там, обьявляем виджет, конфигурируем его, отображаем... ждем "event".

Правильно сказал Flogger_d по поводу совместимостей. Я заметил, что и в ГТК и в КуТе сделаны свои повторения многих стандартных и не очень функций: общение с файлами, строками и т.п. и т.д... Отсюда возникает вопрос, получается, что если реализации определенной функции нет в рамках гтк или куте, то возникают проблемы? Это как-то очень странно в принципе... Получается нужно выбирать ту библиотеку которая поддерживает наибольшее число этих реализаций? Мдя...

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

спасибо за разъяснения!

>>Вопрос как знатоку ГТК. Есть ли там возможность выводить графики, и желательно бегущие... То-есть допустим число меняется от времени, и согласно этому времени на экране ползет график величины числа...

>вообщето можно и бежать будут шустро. Сколько на ето надо потратить времени и как ето делается не скажу ибо ни разу не делал. неудивлюсь если придётся рендерить вручную типа как под досом. возможно придётся написать свой виджет.

Нашел вот такую вещь как gtk+extra, в которой есть набор виджетов gtkplot... Но к сожалению хелп к ней какой-то уж больно куцый :( http://gtkextra.sourceforge.net/

>запусти гугль с ключевыми словами : free math lib linux

Хм и вправду :) наверное я как-то не так запрос формулировал, без слов фрии и линукс. Вот хорошая ссылка.

http://www.thefreecountry.com/sourcecode/mathematics.shtml

однако уже больше 100 комментов :) так можно и в топе оказаться

>Я заметил, что и в ГТК и в КуТе сделаны свои повторения многих стандартных и не очень функций: общение с файлами, строками и т.п. и т.д... Отсюда возникает вопрос, получается, что если реализации определенной функции нет в рамках гтк или куте, то возникают проблемы?

проблемы возникают если тебе надо оперировать данными спецыфичными для конкретной либы. иначе никто тебе немешает юзать стандартные/собственные ф-и.

а вообще использование етих посторений/врапперов и является ключом к портируемости. тоесть если ты открываеш файл средствами glib то тебе не придётся менять код работающий с файлами если ты загочеш скомпилить свою прогу под виндой иначе тебе придётся отдельно писать код для винды.

>Это как-то очень странно в принципе... Получается нужно выбирать ту библиотеку которая поддерживает наибольшее число этих реализаций? Мдя...

>Или нужно развязывать ту часть программы которая рисует и которая считает, говорит с железом и т.п. Что в принципе скорее всего и наиболее хорошая идея. Так как эти части определенно будут востребованы на разных машинах.

здесь я вижу у тебя большое просветление. тоесть даже желательно чтобы ето были не разные модули одной программы а разные программы связанные IPC.

Деточка, тебя разве не учили, что GUI надо жестко отделять от логики. GUI-приложение вообще не должно уметь ничего, кроме отрисовки GUI. Ты брось эти свои дельфовые замашки - в БД из гуёвой программы лезть, в БД должна лезть прослойка, которая про этот GUI ни ухом, ни рылом.

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

>однако уже больше 100 комментов :) так можно и в топе оказаться

Это потому, что тема интересная.

Обрати внимание, что во всех примерах по GTK нет проверки указателей на NULL после вызова функций, которые создают вилжеты. Дело в том, что память под объекты виджетов выделяются функцией g_malloc, которая есть оберткой над malloc. Если malloc вернет NULL, то вызывается abort. Вот тут и самые интересные грабли. Если твоя программа усиленно работает с памятью, а виджеты создаються по ходу выполнения, то вызов abort - дело времени. Пользователю, как говорится, "по барабану", почему упала программа - то ли из-за abort'а, то ли из-за сегфолта.

>здесь я вижу у тебя большое просветление. тоесть даже желательно чтобы ето были не разные модули одной программы а разные программы связанные IPC.

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

>в БД должна лезть прослойка

а как, говорите, это делается? а где, говорите, про это прочитать?

>Это потому, что тема интересная.

спасибо! :)

>Обрати внимание, что во всех примерах по GTK нет проверки указателей на NULL после вызова функций, которые создают вилжеты. Дело в том, что память под объекты виджетов выделяются функцией g_malloc, которая есть оберткой над malloc. Если malloc вернет NULL, то вызывается abort. Вот тут и самые интересные грабли. Если твоя программа усиленно работает с памятью, а виджеты создаються по ходу выполнения, то вызов abort - дело времени. Пользователю, как говорится, "по барабану", почему упала программа - то ли из-за abort'а, то ли из-за сегфолта.

и как с этим борются?

>и как с этим борются? По разному. Ну если число виджетов заранее определено, то после создания всех виджетов не использовать g_malloc. Интересно, что скажут по этому поводу спецы по GIMP? Подозреваю, что там создаються дочерние процессы.

>и как с этим борются?

если вы дошли до того что malloc вернул NULL то здесь уже никак не поборешся. Хоть под Qt хоть под Gtk. в гтк срабатывает стандартный обработчик в Кт пытается возникнуть исключение. в любом случае продолжать работу после такой ситуации особого смысла нету. здесь надо выправлять руки программерам и переписывать приложение.

Пример.

Тянем фрагмент космического снимочека, например на 600M. В добавок, в программе для поддержки работы динамические структуры и промежуточные результаты. Юзер работает под иксами и не видет сообщения на консоли "abnormal program termination...". Окно программы исчезло. Юзер - Б.... Х.... Мать .... а где ...?.

Обычный пользователь графические программы не запускает ни из xterm'a, ни из cmd.exe. Он не узнает что у него памяти на машине мало.

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

Как делается? Пишешь софтину на любом подходящем языке, которая лезет в БД, и общается с *ДРУГОЙ* софтиной, рисующей ГУЙ, через пайпы, по любому удобному тебе протоколу. Так же и в любой другой ситуации - логика отдельно, UI отдельно (любой UI, хоть ГУЙ, хоть CLI, хоть веб).

Ещё один блин любитель лечить мертвецов клизмами...

Если malloc вернул NULL, то никакая там блин интеллехтуальная обработка этой ситуации не поможет. Ты даже не завершишься корректно.

Кури man mmap.

>Тянем фрагмент космического снимочека, например на 600M. В добавок, в программе для поддержки работы динамические структуры и промежуточные результаты. Юзер работает под иксами и не видет сообщения на консоли "abnormal program termination...". Окно программы исчезло. Юзер - Б.... Х.... Мать .... а где ...?.

Наглядный пример кривой архитектуры приложения. Код обрабатывающий данные ДОЛЖЕН работать отдельным процессом результат работы которого гуй может без проблем отследить.

>Обычный пользователь графические программы не запускает ни из xterm'a, ни из cmd.exe. Он не узнает что у него памяти на машине мало.

во первых если на машине нехватаетпамяти то мы получаем не NULL а sigsegv и обработать ету ситуацию практически невозможно ибо попытка создать окно с сообщением приведёт к падению Х-сервера по тому же сигналу.

NULL возвращается в случае нехватки адресного пространства, обычно в силу его большой изрезанности.

обе ети ситуации можно попытатся обработать путём написания обработчика использующего только статическую память. Во втором случае ещё можно попытатся заюзать стек/автоматические переменные

>Ещё один блин любитель лечить мертвецов клизмами...

>Если malloc вернул NULL, то никакая там блин интеллехтуальная обработка этой ситуации не поможет. Ты даже не завершишься корректно

Если malloc вернул NULL я могу сделать откат операции и выдать сообщение юзеру, чтобы он "сохранился". Хорошая интерактивная программа не должна падать сама.

Кстати а почему оси не падают, если превышен запрос по ресурсам. Или выйдете с предложением к Торвальдсу делать "kernel panic", если прикладной программке не хватит памяти?

Да не выведешь ты юзеру никакого сообщения, конечно же. Всё раньше рухнет по sigsegv.

Ещё раз - разберись, наконец, как в линухе виртуальная память устроена.

Задание на дом - воспроизвести искусственно несколько разнородных ситуаций с возвратом NULL из malloc. Убедиться в неработоспособности процесса после подобного события, как и в том, что крайне трудно добиться именно возврата NULL - как правило всё гораздо раньше рухнет по sigsegv.

>Наглядный пример кривой архитектуры приложения. Код обрабатывающий данные ДОЛЖЕН работать отдельным процессом результат работы которого гуй может без проблем отследить.

Угу. Только тормоза выйдут такие, что вас этот юзер съест вместе с тапочками.

>во первых если на машине нехватаетпамяти то мы получаем не NULL а sigsegv и обработать ету ситуацию практически невозможно ибо попытка создать окно с сообщением приведёт к падению Х-сервера по тому же сигналу.

Тут речь идет о нехватке адресного пространтва. Т.е. время от времени могут быть обращения к malloc выделить очень большой участок.

>обе ети ситуации можно попытатся обработать путём написания обработчика использующего только статическую память. Во втором случае ещё можно попытатся заюзать стек/автоматические переменные

Проблема в том, заранее не известно сколько виджетов потребуется. Не понял о каком обработчике идет речь в последней фразе.

>Ещё раз - разберись, наконец, как в линухе виртуальная память устроена.

Прошу у гуру-ананимуса прощение за свою кривую терминологию. Имел в виде не нехватку памяти, а адресного пространства.

Ну и задумайся, как может не хватить адресного пространства маленькой ГУЁвой софтине (а если она получается не-маленькая, то автора - на костёр). Логика то в отдельном процессе работает, со своим адресным пространством.

>Логика то в отдельном процессе работает, со своим адресным пространством.

Эта мысль не дает мне покоя очень давно. К сожалению этот вариант не годится т.к. эти данные нужно отображать в окне один в один. Речь идет об обработке достаточно больших растровых изображений.

>>Наглядный пример кривой архитектуры приложения. Код обрабатывающий данные ДОЛЖЕН работать отдельным процессом результат работы которого гуй может без проблем отследить.

>Угу. Только тормоза выйдут такие, что вас этот юзер съест вместе с тапочками.

kosmonavt, ето ты или не ты?? чёт я тебя неузнаю. Какие тормоза? откудова?? от кривых рук?? ну так повыпрямте программерам руки или о чём речь.

>>во первых если на машине нехватаетпамяти то мы получаем не NULL а sigsegv и обработать ету ситуацию практически невозможно ибо попытка создать окно с сообщением приведёт к падению Х-сервера по тому же сигналу.

>Тут речь идет о нехватке адресного пространтва. Т.е. время от времени могут быть обращения к malloc выделить очень большой участок.

что-то ты невразумительное рассказываеш. если нехватает физической памяти то ядро какомуто процессу пошлёт sigsegv, обычно запросившему. а распределение адресного пространства внутри процесса ему практически паралельно если его никто не использует.

а вот с malloc всё наоборот. у него есть кажись гиг или два адресного пространства которое он выделяет по мере затребования независимо от присутствия физической памяти, которая ему безразлична. и вот если в очередной раз он не смог найти свободный участок то возвращает NULL.

>>обе ети ситуации можно попытатся обработать путём написания обработчика использующего только статическую память. Во втором случае ещё можно попытатся заюзать стек/автоматические переменные

>Проблема в том, заранее не известно сколько виджетов потребуется. Не понял о каком обработчике идет речь в последней фразе.

о обработчике обрабатывающем NULL от malloc(). если закончилось адресное пространство в куче то может быть у нас ещё есть место в стеке что может позволить как-то обработать ету ситуацию

Ну так и давай окошко с картинкой отдельному приложению, а весь GUI - другому.

>>Логика то в отдельном процессе работает, со своим адресным пространством.

>Эта мысль не дает мне покоя очень давно. К сожалению этот вариант не годится т.к. эти данные нужно отображать в окне один в один. Речь идет об обработке достаточно больших растровых изображений.

ну а проблемы какие??? в одной проге ведёш обработку изображения и помещаеш его в шаренную память или файл отображённый в память, другая прям с етой памяти отправляет его Х-серверу на отрисовку а возможно делает ещё какието промежуточные преобразования типа масштабирования. или тебе расказать как ето на gtk реализовать.

ЗЫ: шаренная память выделяется за пределами кучи следственно выделение 500 МБ заренной памяти не уменьшит кучу ни на один байт. ещё способ запросить память за пределами кучи - mmap. а также можеш заранее её статически выделить. всё ето позволяет сэкономить адресное пространство кучи

ему надо логику вынести а не окошко с картинкой, и архитектуру подшаманить. ето вариант на крайний случай.

по-моемому у него весь гуй и так меньше метра занимает если он вообще не окошко с картинкой ;-)

2космонавт:

настойчиво советую: http://www.lukoil.uu.ru/~dalth/linuxlite.pdf

быстро и сердито изучиш основные принципы управления памятью в линукс

а ещё создай отдельный тред и idle && murr добьются твоего просветления а мож и я чемто помогу

Если картинку надо отображать шустро, то тут IPC уже будет лишним, и тогда часть с логикой должна будет уметь делать ровно одну вещь - отобразить заданный кусок картинки в предоставленное ей X-овое окошко.

шаренная память довольно быстрая дабы здесь нормально успевать.

2 cvv

Еще раз повторю дело не в физической памяти.

>о обработчике обрабатывающем NULL от malloc(). если закончилось адресное пространство в куче то может быть у нас ещё есть место в стеке что может позволить как-то обработать ету ситуацию

Проблемка в том, что явный вызов malloc мы можем обработать, но в g_malloc - нет. Отследим несколько вариантов.

1) Вызвали g_malloc при создании виджета - вызов удачный. Затем malloc - неудачный. Тут все просто. 2) Вызвали malloc - вызов удачный. Вызвали g_malloc - неудачный. Вот тут и начинаются грабли. В принципе, можно отследить, НО создание какого-нибудь виджета может повлечь за собой создание дополнительных виджетов и даже не виджетов. Т.е. необходимо грамотно откатить все эти блоки памяти обратно в кучу. В GTK такого механизма не существует. Вот тут и опасения, что проще переписать GTK, чем цеплять этот механизм уже на существующую реализацию.

>kosmonavt, ето ты или не ты?? чёт я тебя неузнаю. Какие тормоза? откудова?? от кривых рук?? ну так повыпрямте программерам руки или о чём речь.

Относительно отделения морды и логики - не тот случай.

Можно делать как в ERDAS IMAGINE - каждому окну по отдельному процессу и ловить код завершения, но GUI и данные все равно придется держать в одном процессе, только идеология разделения другая.

Ну сколько можно? Не надо держать GUI и данные в одном процессе! Просто GUI-процесс создаст окошко и скормит его процессу с логикой, куда тот и будет рисовать. Тривиально. Классика, блин.

>а ещё создай отдельный тред и idle && murr добьются твоего просветления а мож и я чемто помогу

Да не стоит беспокоится. Это моя личная инициатива создания такой програмки. Хотя тему запостить нужно уже давно созрел. Не поверите, но эту програмку я обдумываю уже года три. Пора начинать ее делать. Главная проблема - не в программировании. В двух словах - распознавание текстур. В принципе, математика работает еще с 80-х. Только никак не мог взять в толк, почему даже в комерческих программах этого класса эту самую логику не внедряют. Причина оказалась древней и банальной для этих задач - не могли просчитать размер окна анализа/выборки. Разобравшись пришел к выводу - его и не надо вычислять. Проблема в постановке задачи.

Самое интересное - нах. кому это надо.

Все, покидаю этоу тему.

>Еще раз повторю дело не в физической памяти.

по одному пункту достигли общего мнения

>Проблемка в том, что явный вызов malloc мы можем обработать, но в g_malloc - нет. Отследим несколько вариантов.

кто такое сказал???

если malloc в g_malloc вернул NULL то вызывается g_error() делее вызывается g_logv который собственно и определяет что делать с ошибкой.

поведение g_logv можно изменить по собственному усмотрению до любого состояния, например заставить посылать sms на мобилку.

>НО создание какого-нибудь виджета может повлечь за собой создание дополнительных виджетов и даже не виджетов.

абсолютно верно

>Т.е. необходимо грамотно откатить все эти блоки памяти обратно в кучу.

глубочайшее заблуждение. надо выпрямлять руки программерам а что-то откатывать уже слишком поздно.

>В GTK такого механизма не существует. Вот тут и опасения, что проще переписать GTK, чем цеплять этот механизм уже на существующую реализацию.

посмотрите документацию g_logv и лично убедитесь в своём глубочашем заблуждении.

>Относительно отделения морды и логики - не тот случай.

в смысле???

>но GUI и данные все равно придется держать в одном процессе,

конечно, иначё чё гуй будет отображать. но оставлять в етом же процессе ф-и обрабатывающие ети данные нестоит. ибо они скорее всего потребуют дополнительной памяти с которой у нас и так туго.

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

>g_logv

Ну спасибочки. Вот лажанулся и сам не знаю как. Несколько раз проглядывал исходники, а логику до конца не отследил. Доки нужно внимательно просматривать, а то действительно как кто-то сказал - Сам Себе Злобный Буратино. :-)-

Еще раз спасибо. Ну с shared memory все ясно. Через недельку создам тему.

cvv & kosmonavt

чем больше вас читаю, тем больше ощущаю ту пропасть всего чего я не знаю :) но интересно...

да тут понтов больше, причём с обоих сторон, по крайней мере больше чем диалога. Ну выделяется общая память не в куче, что с того? Адресное пространство между кучей и стэеком уменьшилось - количество доступной памяти уменьшилось. Про виджеты вообще абстрактные предложения без конкретики.

2anonymous

предложи конкретнее... мне интересно.

Например gtk+extra оказалась таки полностью без документации. Я написал, автору, он тоже какой-то физик из европы. Он ответил, что документации нет, но нужные мне вещи там есть. Говорит, что в коде и так все понятно и с комментариями. Похоже прийдется учиться читать код... :(

кстати, для научных целей, есть еще root. Это тоже с++ ная система обработки и отображения данных. Причем можно делать к ней фронтэнд на Куте. Это предусмотренно. Также есть общение с БД, с постгрессом по крайней мере...

Жалко только, что мне основная цель этой системы - обсчет большого объема данных не нужен :(

http://root.cern.ch/

кстати вопрос, на сколько различаются gtk1 и gtk2 по своей сути. нашел книжку по гтк1 на русском печатную. Вот думаю стоит ли ее читать, или правильнее сразу про гтк2...

идеология общая, основным принцыпам научишся а в детали не вникай. gtk2 довольно сильно отличается в деталях реализации. особенно в направлении вывода/рендеринга текста и работы с растровыми картинками

ответ от создателя gtk+extra:

>Hi Petr. I'm affraid that there is no documentation availbale, but the package (the sources) include a very neat, easy to understand, code for real-time plots, testrealtime.c You'll find all the functions are illustrated with a simple example. The other test programs can help to understand more about changin the attributes of the plots as well. Have fund, and don't hesitate to ask any questions. Saludos, <ADRIAN>

>Адресное пространство между кучей и стэеком уменьшилось - количество доступной памяти уменьшилось.

ану расскажи нам чё нить интересного на тему разбиения адресного пространства процесса. а то мы оба с космонавтом здесь плаваем.

насколько я знаю куча имеет фиксированный размер и ядро не может отгрызть часть кучи для своих нужд. Или я ошибаюсь???

> Есть ли там возможность выводить графики, и желательно бегущие... То-есть >допустим число меняется от времени, и согласно этому времени на экране ползет >график величины числа...

Привет. Может забьешь на программирование?

Решал как-то подобную задачу, потребовалось посидеть минут пять с ручкой и бумажкой и написать строчек 50-60 кода.

НАФИГА для этого отдельная библиотека?

>Решал как-то подобную задачу, потребовалось посидеть минут пять с ручкой и бумажкой и написать строчек 50-60 кода.

я думаю что он не раз такую задачу тоже решал только другими средствами, или я ошибаюсь???

если ему больше 25 то скорее я прав

>НАФИГА для этого отдельная библиотека?

например чтобы круче выглядело

Позволь не поверить тебе, что ты это в 50-60 строчек уместил. Рисование графиков - задача архисложная! Ты как подписи размещать будешь, а? Там самое компактное изложение минимального набора эвристических правил займёт пару тысяч строк.

>ану расскажи нам чё нить интересного на тему разбиения адресного пространства процесса. а то мы оба с космонавтом здесь плаваем.

Как всё запущено.

> насколько я знаю куча имеет фиксированный размер и ядро не может отгрызть часть кучи для своих нужд.

Тут нет "насколько я знаю" и прочей неопределённой херни. Не имеет куча "фиксированный размер". Разнообразные .alloc'и именно этим и занимаются, что заказывают у ядра память, та увеличивает кучу отобразив в свободное адресное пространство физическую память. "Отгрызает", ёпт.

Сверху вниз в свободную память растёт стэк, а куча в ту же самую память снизу вверх.

FFFFFFFF

-------------

стэк

------------- -------------

ОБЩЕЕ СВОБОДНОЕ АДРЕСНОЕ ПРОСТРАНСТВО

------------- -------------

КУЧА

------------- -------------

данные инициализированные и нет, текст

-------------

00000000

хм. странно. никогда не думал что malloc() в ядро лезет:

bash-2.05b$ cat t5.c #include <stdlib.h> #include <unistd.h>

int main(){ write(1,"start malloc()",15); malloc(1024*8); write(1,"stop malloc()",14); } bash-2.05b$ gcc -o t5 t5.c bash-2.05b$ strace ./t5 execve("./t5", ["./t5"], [/* 47 vars */]) = 0 brk(0) = 0x8049600 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/oracle/app/oracle/product/8.1.7/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/oracle/app/oracle/product/8.1.7/lib/i686/mmx", 0xbfffe8e0) = -1 ENOENT (No such file or directory) open("/oracle/app/oracle/product/8.1.7/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/oracle/app/oracle/product/8.1.7/lib/i686", 0xbfffe8e0) = -1 ENOENT (No such file or directory) open("/oracle/app/oracle/product/8.1.7/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/oracle/app/oracle/product/8.1.7/lib/mmx", 0xbfffe8e0) = -1 ENOENT (No such file or directory) open("/oracle/app/oracle/product/8.1.7/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/oracle/app/oracle/product/8.1.7/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=66635, ...}) = 0 old_mmap(NULL, 66635, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40015000 close(4) = 0 open("/lib/libc.so.6", O_RDONLY) = 4 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300X\1"..., 1024) = 1024 fstat64(4, {st_mode=S_IFREG|0755, st_size=1454172, ...}) = 0 old_mmap(NULL, 1268580, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40026000 mprotect(0x40154000, 31588, PROT_NONE) = 0 old_mmap(0x40154000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x12d000) = 0x40154000 old_mmap(0x4015a000, 7012, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4015a000 close(4) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4015c000 munmap(0x40015000, 66635) = 0 write(1, "start malloc()\0", 15start malloc()) = 15 brk(0) = 0x8049600 brk(0x804a600) = 0x804a600 brk(0) = 0x804a600 brk(0x804b000) = 0x804b000 brk(0) = 0x804b000 brk(0x804c000) = 0x804c000 write(1, "stop malloc()\0", 14stop malloc()) = 14 semget(14, 0, 0) = -1 ENOSYS (Function not implemented) _exit(14) = ? bash-2.05b$

Хм. неплохо. на один маллок 6 системных вызовов. а я то думал. а он оказывается настоящий тормоз.

кстати а что делает brk(0)???

чтото у меня совсем потемнение.

где idle && murr???