|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Timothey Sleptsov 2:5020/400 06 May 2002 19:41:19
To : Ilya Anfimov
Subject : Re: Программерский вопрос
--------------------------------------------------------------------------------
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, что ты описал чуть ниже там отсутствуют.
> >Hасчет кривизны API, я ничего кроме неудачного названия функции msgget
> >придумать не могу. Все остальное меня полностью устраивает.
>
> Отсутствие отображения этой бни в нормальные файловые
> дескрипторы (в частности, select/poll отправляются курить);
> какое-то уродство с именованием; малоюзабельное уродство с
> правами (да, классическая схема. Hо в классической схеме это
> ложилось на иерархию объектов, и в конечном итоге,
> поманипулировав с путём в этой иерархии, обычно можно добиться
> желаемого результата); Тупик с расширением на сетевые
> конфигурации (я ещё могу понять про shm -- его технически
> неэффективно по сети гонять. Hо остальное...)
>
> Этого мало? Спросите у тех, кто с этим активно работал -- думаю,
> они ещё подскажут.
А что тут спорить, большинство правда, кроме рассуждений о правах,
убогости там нет, просто это следствие того SysV ipc не отображается,
как ты уже сказал в файловые дескрипторы. В принципе я и сам могу
продолжить SysV IPC объект расположен в адресном пространстве ядра
(переключение контекста), ключи целочисленные ( а не файловые имена ).
Поэтому еще раз говорю панацея от таких заморочек ipc posix 1b. Видел
в инете patch для 2.4.x с posix mqueue.
> >Ты назвал 2 ipc из 3 предложенных SysV. Согласись неплохой результат
>
> Я назвал 1.5 из 3. И того, что хочешь использовать ты, в этих
> 1.5 не нашлось.
семафоры + разделяемая память = 2 ipc метода ipc. Из трех, не берем в
счет BSD sockets и TLI.
> >сообщения отсылать. Зато вот что прикольно, сдохнет у пипла клиент, он
> >заново подрубиться, а ему мессага из очереди ;) Или сервер кинется,
> Вот радость-то. То есть послал клиент мессагу, и хрен его знает
> -- принял её кто, не принял...
Hе совсем все так запущено, есть структура msqid_ds, в ней поле
msg_lspid - это pid процесса последнего прочитавшего сообщения из очереди
> Да всё равно на столь
> низкоуровневом протоколе придётся какие-нибудь мелочи при
> соединении друг другу говорить.
Может придется, а может и нет, в моем проекте не пришлось.
> Кстати, к вопросу об именах -- как это ты собрался клиента к той
> же очереди подрубать? И чтобы ничего не пропало?
> btw, а как ты собрался работать с одной очередью на n процессов?
> Синхронизировать получение с помощью ещё чего-то? А не
> заколебёшься?
Зачем??? Если открыть любую хорошую книжку на разделе IPC SysV, и
посмотреть api очереди сообщений ( например Теренса Чана ), то при
прочтении можно узнать что сообщение это структура, в которой есть
поле mtype типа long. При отсылке сообщения клиент пишет в это поле
1. А в поле буфера сообщения структуру ( cвой pid + текст мессаги ).
Сервер читает все сообщения в очереди, mtype которых равен 1,
обрабатывает их и результат отсылает процессам, но теперь полю mtype
присваивается pid процесса которые должен получить сообщение. А каждый
клиентский процесс читает сообщения с mtype равным его pid. Очень
сложно да? ;) Hазывается мультиплексирование сообщений в
очереди..
--
Best regards
Timothey Sleptsov
e-mail: tim_sleptsov@fromru.com
tim_sleptsov@mtu-net.ru
--- ifmail v.2.15dev5
* Origin: Golden Telecom (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
