OSDev

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

А что мешает сделать сообщения с ответами? Или чётко оговорить: если задача посылает сообщение с запросом на то-то, то ей в ответ придёт сообщение с тем-то?

Что именно вы подразумеваете под сообщениями с ответами? Сообщения с определёнными номерами? Или так: существует два системных вызова: send_message и send_message_with_result. Если with_result, то нить в своём дескрипторе устанавливает флаг того, что ждёт результат от такой-то нити. В свою очередь нить, обрабатывающая сообщение, вызывает send_message_result. Он проверяет, что нить, пославшая сообщение, ждёт результат именно от текущей нити и если так, то копирует результат в память процесса, чья это была нить. Как лучше? И как это реализаовано в том же Windows (просто я знаю, что в Windows есть SendMessage, возращяющий результат. с Linux я знаком намного меньше, поэтому привожу в пример не его)?

В любом случае клиент запрашивает у сервера (драйвера) ответное сообщение с результатами опрерации (уведомление). Если драйвер реализует консоль в виде потока (дочернего), то в уведомлении отсылает id (например) консоли, который сам запрашивает у ядра при её создании. Но для этого необходимо реализовать поддержку двух видов уведомлений - блокирующие и неблокирующие. Иначе, если клиент при отправке блокируется, то попытка сервера отослать клиенту сообщение приведёт к взаимной блокировке. Посмотрите, как это реализуется в Миникс 3. Там как-то просто это решается)) Ну или я спрошу у Таненбаума, но это только вечером)

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

KIV, естественно нужно будет создавать протоколы взаимодействия, и следовать им. В Windows процедура SendMessage всегда ждёт ответа от получателя и возвращает результат. Ещё есть PostMessage, которая отправляет сообщения без обратной связи.
Согласен с Mr.McD., что поток ожидающий ответа, сам должен быть в режиме приёма и обработки всех сообщений.
Похоже, что клиент должен использовать SendMessage(), а сервер отвечать процедурой PostMessage(), ведь серверу ответ от клиента не нужен.

Я думаю сделать так: ожидание результата блокирует нить, но есть такая вещь как таймауты. Часто нити не имеет смысла продолжать работу пока она не получила результат запроса. Если нити придётся получать сообщения, чтобы узнать результат, то программист будет делать различные проверки: а может ли нить обработать сообщение не получив результат от сервера и т. п. Таймауты нужно, чтобы при обращении клиента к зависшему серверу (или сервера к зависшему клиенту), если нить может продолжить работу без получения результата (например, сервер графической подсистемы просит перерисовать окно, а клиент завис. сервер может спокойно переживёт, то что окно не обновилось и продолжит работу. причём если каждое окно - отдельная нить в сервере, то это даже не отразится на других окнах. конечно, это лишь пример, GUI я пока делать не собираюсь и обсуждать недостатки моего примера не надо). Ну а если программист хочет, чтобы программа не зависала, например, на время чтения файла, то читать надо в отдельной нити.

Обрабатывать таймауты можно примерно так:

Считаем, что WaitMessage() блокирует поток до прихода сообщения, или истечения заданного времени. Возвращает true при наличии, или false при отсутствии сообщения.
PeekMessage() записывает сообщение в первый параметр.

KIV, а зачем здесь таймаут?! Если нить МОЖЕТ продолжать работу без результатов ответа, то используйте сообщения типа POST. (она не заблокируется)
А если Вы использовали SEND (нить отправитель блокируется), а получатель "висит", то тут таймаут как нельзя кстати - отличный повод рестартовать получателя.(ну или просто выдать ошибку "получатель не отвечает")

*SEND используется какраз тогда, когда нить НЕ МОЖЕТ продолжать работу без результов ответа.

Я года три назад тоже думал над этим вопросом. В результате все придумал, и даже реализовал ядро ОС, в которой все IPC построено на сообщениях. Получилось весьма красиво, но... Оказалось, что драйвера для этой системы писать ЖУТКО неудобно. Ведь назначение драйвера - правильно работать со специфическим оборудованием, а тут ему (и программисту) приходится тратить кучу сил на то, чтобы корректно разгребать очередь сообщений. В результате я объявил эту свою ОСь тупиковой и больше ее не поддерживаю (хотя она до сих пор у нас используется для некоторых задач).