Длинный переход корректно работает со стеком. При входе в точку, установленную с помощью setjmp, он восстанавливает все то состояние (в том числе и состояние стека), которое было при установке этой точки. Надо заметить, что longjmp восстанавливает не сам стек, а лишь указатель стека.
Работа со стеком всегда должна удовлетворять правилу: перед обращением к функции и после возврата из нее, уровень стека должен быть одинаковым. Если уровень станет больше или меньше, это гарантировано приведет к проблемам, потому что рано или поздно стек либо переполнится, либо программа полезет за нижний его уровень, что тоже плохо.
Вопрос: предположим мы установили setjmp в некоторой функции, мы вернулись из этой функции, и затем выполнили переход longjmp (т.е. вошли в функцию не сначала). Куда при выходе из этой функции произойдет возврат, потому что в общем случае содержимое стекового кадра этой функции будет случайным (т.к. в буфере env содержится указатель стека, а не сам стек)? Возврат произойдет корректно, т.к. в буфере env адрес возврата будет сохранен, а вот значения автоматических и регистровых переменных этой функции действительно окажется случайным, потому что стек в буфере не сохраняется. Но это есть правила игры. Т.е. здесь на решение программиста налагается ответственность.
До сих пор мы с вами рассматривали взаимодействия, связанные с родственными процессами. Реально, система UNIX имеет набор средств, поддерживающих взаимодействие произвольных процессов. Одно из таких средств - Система Межпроцессного Взаимодействия IPC (InterProcess Communications). Суть этой системы заключается в следующем.
Имеется некоторое количество ресурсов, которые называются в системе разделяемыми. К одному и тому же разделяемому ресурсу может быть организован доступ со стороны произвольного количества произвольных процессов. При этом возникает проблема именования этих разделяемых ресурсов. Если мы вспомним неименованные каналы, за счет того, что каналы передавались по родственному наследованию, всегда в процессе были известны дескрипторы, ассоциированные с каналом. Фактически, если процесс получал доступ к каналу, он уже знал, как именовать этот канал. Здесь использовалось свойство родственной связи, когда какая-то информация, какие-то средства передаются по наследству при формировании сыновьего процесса.
В системе IPC ситуация другая. Есть некоторый ресурс, в общем случае произвольный, и к этому ресурсу могут добираться все, кто может именовать этот ресурс. Для именования такого рода ресурсов в системе предусмотрен механизм генерации т.н. ключей. Суть его заключается в следующем. По некоторым общеизвестным данным (это могут быть текстовые строки или цифровые комбинации) в системе генерируется уникальный ключ, который ассоциируется с разделяемым ресурсом. Если процесс подтверждает этот ключ и созданный разделяемый ресурс доступен для него, то после этого он может работать с указанным разделяемым ресурсом по своему усмотрению.
Разделяемый ресурс создается некоторым процессом-автором. Автор определяет основные свойства ресурса (предположим, размер) и права доступа. Права доступа к ресурсу разделяются на три категории:
Права доступа самого автора.
Права доступ всех процессов, имеющих тот же идентификатор что и автор.
Права доступа остальных.
Итак, система позволяет некоторому процессу создать разделяемый ресурс, защитить его некоторым ключом и забыть о его существовании. После этого все те, кто знают ключ, который открывает этот ресурс, могут работать с содержимым этого ресурса. Возникают проблемы синхронизации доступа к разделяемому ресурсу. Решение этих проблем и другие концептуальные возможности предоставляет система IPC. Начиная со следующей лекции, мы будем рассматривать конкретные средства системы IPC.
Система IPC поддерживает три разновидности разделяемых ресурсов:
Разделяемая память. Концептуально - это возможность нескольких процессов иметь общее поле оперативной памяти, и соответственно работать с этим полем, как с неким массивом, на который имеется указатель. Проблема синхронизации здесь стоит особенно остро, но базово средства работы с разделяемой памяти никакой синхронизации не предполагают.
Механизм передачи сообщений. Разделяемым ресурсом здесь является очередь сообщений. Эта очередь может содержать произвольное количество (в пределах разумного) сообщений разной длины и разного типа. Тип сообщения - это некоторый атрибут сообщения. Очередь сообщений может рассматриваться как единая очередь всех сообщений в хронологическом порядке, и как множество очередей, содержащих сообщения определенного типа, где в каждой очереди также есть хронологический порядок.Здесь также возникают проблемы синхронизации.
Семафоры. Семафоры - это нечто, что позволяет синхронизовать доступ к разделяемым ресурсам.