|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 06 May 2002 20:26:15
To : Timothey Sleptsov
Subject : Re: Программерский вопрос
--------------------------------------------------------------------------------
On Mon, 6 May 2002 15:41:19 +0000 (UTC),
Timothey Sleptsov <tim_sleptsov@fromru.com> wrote:
>ilan@adt.ru (Ilya Anfimov) writes:
>
>> 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.
>SysV ipc будет славно работать под Solaris, FreeBSD, Linux.
>
>А вообще я считаю, что пора переходить posix 1b ipc. Все те минусы
>SysV ipc, что ты описал чуть ниже там отсутствуют.
Там видно наличие отсутствия портабельности. Как минимум. Да,
это не к API. Hо это лечиться лет пять.
Вообще, надо будет заняться самообразованием на досуге. :-).
По сравнивать mach, posix 1b со своим пониманием, что же не
должно быть в ipc.
>> >Hасчет кривизны API, я ничего кроме неудачного названия функции msgget
>> >придумать не могу. Все остальное меня полностью устраивает.
>>
>> Отсутствие отображения этой бни в нормальные файловые
>> дескрипторы (в частности, select/poll отправляются курить);
>> какое-то уродство с именованием; малоюзабельное уродство с
>> правами (да, классическая схема. Hо в классической схеме это
>> ложилось на иерархию объектов, и в конечном итоге,
>> поманипулировав с путём в этой иерархии, обычно можно добиться
>> желаемого результата); Тупик с расширением на сетевые
>> конфигурации (я ещё могу понять про shm -- его технически
>> неэффективно по сети гонять. Hо остальное...)
>>
>> Этого мало? Спросите у тех, кто с этим активно работал -- думаю,
>> они ещё подскажут.
>А что тут спорить, большинство правда, кроме рассуждений о правах,
>убогости там нет, просто это следствие того SysV ipc не отображается,
>как ты уже сказал в файловые дескрипторы. В принципе я и сам могу
Вот если делали так, то и сделали бы какую-нибудь другую схему
правораздачи.
[skipped]
>> >Ты назвал 2 ipc из 3 предложенных SysV. Согласись неплохой результат
>>
>> Я назвал 1.5 из 3. И того, что хочешь использовать ты, в этих
>> 1.5 не нашлось.
>семафоры + разделяемая память = 2 ipc метода ipc. Из трех, не берем в
>счет BSD sockets и TLI.
Я сказал, что разделяемую память используют, семафоры иногда
используют для контроля разделяемой памяти. Поскольку сегментов
обычно не так много, то реальной нагрузки на них всё равно мало.
Потому и считаю это так, слегка используемым.
[skipped]
>> btw, а как ты собрался работать с одной очередью на n процессов?
>> Синхронизировать получение с помощью ещё чего-то? А не
>> заколебёшься?
>Зачем??? Если открыть любую хорошую книжку на разделе IPC SysV, и
>посмотреть api очереди сообщений ( например Теренса Чана ), то при
>прочтении можно узнать что сообщение это структура, в которой есть
>поле mtype типа long. При отсылке сообщения клиент пишет в это поле
Да, про распределение и msqid -- стормозил. Я что-то это только
как приоритет воспринимал. Впрочем, при 1K клиентов я уже говорил
про то, что от DOSов вряд ли избавишься.
>1. А в поле буфера сообщения структуру ( cвой pid + текст мессаги ).
>Сервер читает все сообщения в очереди, mtype которых равен 1,
>обрабатывает их и результат отсылает процессам, но теперь полю mtype
>присваивается pid процесса которые должен получить сообщение. А каждый
>клиентский процесс читает сообщения с mtype равным его pid. Очень
>сложно да? ;) Hазывается мультиплексирование сообщений в
>очереди..
>
>
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: Программерский вопрос 
