|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 06 May 2002 12:29:24
To : Timothey Sleptsov
Subject : Re: Программерский вопрос
--------------------------------------------------------------------------------
On Mon, 6 May 2002 07:05:47 +0000 (UTC),
Timothey Sleptsov <tim_sleptsov@fromru.com> wrote:
>ilan@adt.ru (Ilya Anfimov) writes:
>
>> >msgget, msgrcv, msgsnd
>>
>> Это который SYSV IPC? Могу посоветовать не связываться. API там
>> довольно кривое, портабельность довольно низкая.
>Между Unix'ами портабельность хорошая, более чем. Возникают проблемы,
Бывает существенно более. Даже между unixами. И потом, не unix
единым. А всё, что более-менее похоже на современные unices,
скорее всего придёт вообще без SYSV IPC.
>причем очень неприятные, при перетаскивание проекта под Win. Очередь
>сообщений в Win отсутствует.
Включая MS Win.
>
>Hасчет кривизны API, я ничего кроме неудачного названия функции msgget
>придумать не могу. Все остальное меня полностью устраивает.
Отсутствие отображения этой бни в нормальные файловые
дескрипторы (в частности, select/poll отправляются курить);
какое-то уродство с именованием; малоюзабельное уродство с
правами (да, классическая схема. Hо в классической схеме это
ложилось на иерархию объектов, и в конечном итоге,
поманипулировав с путём в этой иерархии, обычно можно добиться
желаемого результата); Тупик с расширением на сетевые
конфигурации (я ещё могу понять про shm -- его технически
неэффективно по сети гонять. Hо остальное...)
Этого мало? Спросите у тех, кто с этим активно работал -- думаю,
они ещё подскажут.
>
>> Учитывая, что
>> единственное, что из этой кучи хлама действительно массово
>> используется Shared Memory и (уже немного реже) семафоры для его
>> (Shared Memory) синхронизации,
>Ты назвал 2 ipc из 3 предложенных SysV. Согласись неплохой результат
Я назвал 1.5 из 3. И того, что хочешь использовать ты, в этих
1.5 не нашлось.
>когда 2/3 твоей технологии массово используется?
>
>> можно предположить, что с
>> очередями сообщений при большой нагрузке будут всплывать если не
>> тонкие глюки, то по крайней мере проблемы с производительностью.
>С очередями хуже, у них размер ограничен, придется в несколько заходов
>сообщения отсылать. Зато вот что прикольно, сдохнет у пипла клиент, он
>заново подрубиться, а ему мессага из очереди ;) Или сервер кинется,
Вот радость-то. То есть послал клиент мессагу, и хрен его знает
-- принял её кто, не принял... Да всё равно на столь
низкоуровневом протоколе придётся какие-нибудь мелочи при
соединении друг другу говорить. Так что само -- не сработает. А
при наличии рук -- так будет при любом протоколе, хоть flopЅ
pynetом с регулярными попаданиями гонцов в запой ты пересылай.
>заново загрузим, и все мессаги в очереди, пойдут куда надо. Одна
>проблема системные ресурсы и ограничения ядра.
Кстати, к вопросу об именах -- как это ты собрался клиента к той
же очереди подрубать? И чтобы ничего не пропало?
btw, а как ты собрался работать с одной очередью на n процессов?
Синхронизировать получение с помощью ещё чего-то? А не
заколебёшься?
>> Вообще, лучше бы оно и вовсе не появлялось. Вместо этого уже
>> довели бы mmap до ума.
>Hасчет того, чтобы не появлялось ты не прав, ой как не прав, слишком
>много хороших программ используют SysV ipc. Вот бы posix 1b ipc
Если бы оно не появлялось, то эти программы, как это не
удивительно, его бы не использовали. Hаверное, они использовали
бы что-то другое.
>появилось в нормальном виде...а так пока mmap.
>
>--
>Best regards
>Timothey Sleptsov
>
>e-mail: tim_sleptsov@fromru.com
> tim_sleptsov@mtu-net.ru
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
