Windows послать сигнал процессу

NOTE: The method I’m about describe only works for processes who’s source code is under your control. If you want a way to generically signal any running process (e.g. search for a list of running OS and 3rd-party processes that might interfere with your installer and signal them to terminate) then this is not what you want.

A Bit of Background

A similar problem to the one we are discussing here is signaling all running threads to terminate. The idea is that there could be multiple places in the code where an application might need to initiate a process termination, but you need to synchronize that across all threads and allow them to perform their own cleanup. One way to do this is have long running threads periodically check to see if they should shutdown by checking to see if an event is signaled.

Windows Events

On the Windows platform when an event object is created it is done so in an object namespace. In addition to the ability to create your own private namespaces, there are also two special kernel object namespaces – Global and Local. There is a Local namespace associated with each client session on the machine. By default the Local namespace is used for any object created by a process that was started under a client session. As the name implies, there is a single Global namespace system-wide. The Global namespace is used primarily by system services but can also be used by client session processes by prefixing the event name with “Global\”.

The CreateEvent function is used to (surprise!) create an event. It can create either a named or unnamed event. If you use a named event and the named event already exists before the call to CreateEvent then the function returns a handle to the existing object and GetLastError returns ERROR_ALREADY_EXISTS. By creating a named event, the OS enforces that only a single instance of the object exists in that namespace at any one time and that all processes referring to that event will receive a handle to the same instance, creating a form of interprocess communication. Thus if the Local namespace is used, then the event object is shared across all processes that refer to it in that client session. Likewise if it is created in the Global namespace, it is shared across all processes that refer to it on the entire system.

There are two reset mechanisms used by event objects: AutoReset and ManualReset. An AutoReset event will automatically be reset to a non-signaled state as soon as single waiting thread is released. A ManualReset event requires a call to ResetEvent in order to be returned to a non-signaled state.

Lastly, an event can be set to either the signaled or non-signaled state when it is initially created.

Signal Terminate via Named Event Object

By combining the concept of checking for a signaled event to determine when to shutdown and using a named event object, it is possible to signal one process to shutdown via another process. By using an event object created in the Local namespace you can signal processes across a single client session. Conversely by using an event object created in the Global namespace you can signal processes across the entire system.

When creating the terminate event object you want to use a ManualReset event created in the non-signaled state initially. If it were instead an AutoReset event, then as soon as one of the waiting threads from any of the processes was released, the event would return to the non-signaled state. This would result in only a single thread receiving the terminate message, which is not what we want. As for the state, if it were instead initially signaled then the threads would begin terminating as soon as they started running and began checking the event.

Below is an example of creating a named ManualReset event in the Local object namespace that is intially non-signaled. I’m using a GUID for the object name to avoid the potential for unintentional naming collisions with other applications. While a GUID is probably overkill, using a name like “shutdown_event” probably isn’t a good idea.

static const LPCSTR fp_terminate_event_name =
   "Local\\0BAF85D0-0786-4cbf-AF3B-E36322382DBF";

// Create a manual-reset event in the non-signaled state
fh_terminate_event =
  CreateEvent( NULL,                              // default security attributes
               TRUE,                              // manual-reset event.
               FALSE,                             // initial state is non-signaled
               TEXT( fp_terminate_event_name ) ); // object name

os.kill(pid, signal.CTRL_C_EVENT)

то не получится связать этот сигнал с обработчиком в порождённом подпроцессе, так как попытка такой связки (то есть попробовать связать обработчик с сигналом в “коде подпроцесса”):

def handle(signum, frame):
	print("I have signal with num = {0}!!!!!".format(signum))
signal.signal(signal.CTRL_C_EVENT, handle)

приведёт к вылету интерпретатора с ошибкой:

signal.signal(signal.CTRL_C_EVENT, handle)
ValueError: invalid signal value

То есть, эти “виндовс-спесифик” сигналы можно использовать только в os.kill, но не в задании обработчка — signal.signal о_0

Собственно, подскажите пожалуйста, имеется ли какой-либо способ уведомить пораждённый подпроцесс (то есть, уже созданный ранее) о каком-либо событии,

имея только его PID

, без использования каких-либо других объектов синхронизации??

Отредактировано (Ноя. 2, 2011 03:31:39)

Посылка сигнала Windows процессу — все, что вам нужно знать

Одной из важных функций операционной системы Windows является отправка сигналов процессам. Сигналы — это сообщения, которые Windows посылает процессам для общения и контроля их поведения. Когда Windows отправляет сигнал процессу, она дает ему определенную команду или указание, которые процесс должен выполнить.

Windows использует сигналы для множества различных задач. Например, сигналы могут быть использованы для прекращения работы процесса, приостановки его выполнения, возобновления после приостановки, изменения приоритета выполнения и многого другого. Это позволяет операционной системе контролировать и управлять процессами, обеспечивая их правильное и эффективное функционирование.

Отправка сигналов процессам в Windows происходит через различные механизмы, включая использование системных вызовов и API. Эти механизмы позволяют приложениям и системным компонентам взаимодействовать друг с другом и осуществлять контроль над процессами.

Различные сигналы имеют разное значение и влияние на процессы. В зависимости от типа отправленного сигнала, процесс может изменить свое поведение, завершиться, прекратить работу или выполнить другие действия, предписанные операционной системой.

Понимание работы сигналов в операционной системе Windows является важным аспектом для разработчиков и администраторов систем. Это позволяет им эффективно управлять и контролировать процессы в системе, обеспечивая их безопасность и оптимальную производительность.

В этой статье мы более подробно рассмотрим, как Windows отправляет сигналы процессам, типы доступных сигналов и их воздействие на процессы. Мы также рассмотрим примеры использования сигналов в различных сценариях и дадим рекомендации по эффективному использованию этой функциональности операционной системы.

Что такое сигналы в ОС Windows и как они взаимодействуют с процессами

Сигналы в Windows выполняют различные функции, включая уведомление процесса о каком-либо событии, прерывание выполнения процесса, изменение поведения процесса и даже завершение процесса. Операционная система может отправить сигнал процессу, когда происходит определенное событие, такое как нажатие клавиши или завершение работы другого процесса.

Процессы в Windows могут быть запущены с различными приоритетами, и сигналы могут использоваться для изменения этого приоритета. Например, сигнал может быть отправлен процессу для того, чтобы попросить его временно снизить свой приоритет и уступить ресурсы другому процессу. Сигналы также используются для прекращения выполнения процесса, если возникают проблемы или ошибки в программе, либо для вынужденного завершения процесса, который не реагирует на обычные команды завершения.

Взаимодействие сигналов и процессов в операционной системе Windows осуществляется посредством функций API, таких как SetConsoleCtrlHandler и GenerateConsoleCtrlEvent. С помощью этих функций процессы могут зарегистрировать обработчики сигналов и отправлять сигналы другим процессам. Кроме того, системные сигналы, такие как сигнал завершения, могут быть обработаны операционной системой без участия приложения.

Как ОС Windows отправляет сигналы процессам

Операционная система Windows имеет сложную систему взаимодействия с процессами, включая отправку сигналов. Сигналы представляют собой особые сообщения, которые операционная система отправляет для уведомления процессов о различных событиях или изменениях состояния. Они могут быть использованы для запуска или завершения процессов, а также для управления их выполнением.

Windows поддерживает несколько типов сигналов, каждый из которых имеет свою специфическую цель. Например, сигнал SIGINT (Interrupt Signal) используется для прерывания процесса по запросу пользователя, например, при нажатии на комбинацию клавиш Ctrl+C. Сигнал SIGTERM (Terminate Signal) используется для завершения процесса по запросу операционной системы или другого процесса. И есть еще много других типов сигналов, каждый со своими особенностями и назначением.

Отправка сигнала процессу в Windows может осуществляться различными способами. Один из них — использование функции GenerateConsoleCtrlEvent из библиотеки kernel32.dll. Эта функция позволяет отправить сигнал конкретному процессу или группе процессов, исходя из их идентификаторов. Другой способ — использование утилиты taskkill, которая позволяет отправить сигнал завершения процессу по его имени или идентификатору.

Процессы могут обрабатывать поступающие сигналы по-разному. Некоторые процессы могут игнорировать определенные сигналы или выполнять специальные действия при их получении. Например, для обработки сигнала SIGINT многие приложения реагируют на него с помощью нежелательных прерываний работы, сохраняя прогресс или выполняя другие действия перед завершением процесса. В то же время, другие процессы могут использовать сигналы для безопасного завершения работы, освобождения ресурсов и сохранения данных.

Пример использования функции GenerateConsoleCtrlEvent в языке программирования C++:


#include <iostream>
#include <windows.h>
int main() {
DWORD processId = 123; // идентификатор процесса, которому будет отправлен сигнал
GenerateConsoleCtrlEvent(CTRL_C_EVENT, processId);
return 0;
}


Понятие сигналов в операционных системах

Сигналы являются важным механизмом взаимодействия между процессами в операционной системе. Они могут быть отправлены для оповещения другого процесса о различных событиях, таких как завершение процесса, ошибка или изменение состояния процесса. При получении сигнала процесс может выполнить различные действия, например, завершить свое выполнение, обработать ошибку или изменить свое состояние.

В Windows сигналы могут быть отправлены с помощью функции SendMessage или PostMessage. SendMessage отправляет синхронный сигнал, который блокирует отправляющий процесс до получения ответа, в то время как PostMessage отправляет асинхронный сигнал, который не блокирует отправляющий процесс. Когда процесс получает сигнал, он может обработать его с помощью функции WndProc, которая является частью его окна.

Сигналы в операционных системах имеют различные цели и функции. Они позволяют системе контролировать процессы, обмениваться информацией и уведомлять о событиях. Понимание работы сигналов в операционной системе важно для разработки эффективных и надежных программных приложений. Сигналы предоставляют разработчикам возможность управлять и синхронизировать процессы, обрабатывать ошибки и уведомлять о событиях в операционной системе.

• Сигналы используются для отправки сообщений между процессами.
• Они позволяют процессам взаимодействовать и обмениваться информацией.
• Сигналы могут быть отправлены для уведомления о различных событиях.
• Полученный сигнал может быть обработан и использован процессом в своей логике работы.

Понимание работы сигналов в операционных системах является важным аспектом для разработки программного обеспечения.

Основные типы сигналов в ОС Windows

В Windows существуют несколько основных типов сигналов:

• SIGINT: Это сигнал прерывания, который отправляется процессу при нажатии клавиши Ctrl+C в командной строке или при вызове функции GenerateConsoleCtrlEvent. Процесс может обработать этот сигнал и выполнить соответствующие действия, например, корректно завершить свою работу.
• SIGBREAK: Этот сигнал также связан с прерыванием, но он отправляется процессу при нажатии комбинации клавиш Ctrl+Break в командной строке. Он используется для обработки прерываний, которые требуют более резкого или немедленного реагирования.
• SIGTERM: Этот сигнал указывает процессу на запрос его завершения. Он может быть отправлен из другого процесса или из системы операционной системы Windows. Когда процесс получает этот сигнал, он может корректно завершить свою работу и очистить свои ресурсы.

Каждый из этих типов сигналов имеет свое назначение и предназначен для использования в определенных ситуациях. Обработка сигналов в процессах Windows позволяет эффективно управлять выполнением программ и уведомлять другие процессы о важных событиях. Основные типы сигналов в ОС Windows — это важный аспект программирования и разработки под эту операционную систему.

Механизм отправки сигналов в ОС Windows

Один из наиболее распространенных сигналов в ОС Windows — сигнал Ctrl+C, который обычно используется для прерывания выполняющегося процесса или программы. Когда пользователь нажимает сочетание клавиш Ctrl+C, операционная система отправляет соответствующий сигнал процессу, который затем может обработать его и выполнить необходимые действия, например, завершить свою работу и освободить ресурсы.

Другой важный сигнал — сигнал Ctrl+Break, который также может быть использован для прерывания процесса. Однако, в отличие от Ctrl+C, этот сигнал имеет более высокий приоритет и может быть использован для принудительного завершения даже заблокированного процесса.

Операционная система Windows также предоставляет программным приложениям возможность отправлять сигналы другим процессам. Это может быть полезно, например, для уведомления другого процесса о наступлении определенного события или передачи информации. Для отправки сигнала от одного процесса к другому используется функция GenerateConsoleCtrlEvent, которая позволяет указать целевой процесс и тип отправляемого сигнала.

Как процессы в ОС Windows реагируют на сигналы

В Windows существует несколько типов сигналов, которые могут быть отправлены процессу. Один из наиболее распространенных сигналов — это сигнал остановки, который отправляется системой для принудительного завершения процесса. Когда процесс получает такой сигнал, он должен прекратить свою работу и корректно завершить свою работу, освободив все ресурсы, которые он использовал.

Кроме того, сигналы могут использоваться для отправки пользовательских команд процессам. Например, сигнал «Ctrl+C» может быть отправлен процессу для прерывания его выполнения и выхода из программы. Это полезно в случае, когда процесс выполняется в бесконечном цикле или затянулся с выполнением задачи. Процесс должен обрабатывать этот сигнал и корректно завершать свою работу, чтобы избежать возможности повреждения данных или иные проблемы.

В целом, понимание того, как процессы в ОС Windows реагируют на сигналы, является важным аспектом разработки программного обеспечения. Разработчики должны быть в состоянии обрабатывать сигналы, чтобы гарантировать стабильность и безопасность своих приложений. Администраторы системы также должны иметь понимание о воздействии сигналов на процессы, чтобы эффективно управлять состоянием своей системы и реагировать на различные ситуации и проблемы.

Возможные проблемы и ошибки при отправке сигналов в ОС Windows

Отправка сигналов в операционную систему Windows может столкнуться с рядом проблем и ошибок, которые могут затруднить нормальную работу программы или приложения. В этой статье мы рассмотрим некоторые из этих проблем и предложим решения для их устранения.

1. Ошибка неверного идентификатора процесса

Одной из наиболее распространенных проблем при отправке сигналов в ОС Windows является неверный идентификатор процесса. Это может произойти, если процесс был завершен или если был указан неправильный идентификатор. Для решения этой проблемы необходимо убедиться, что идентификатор процесса указан правильно, и проверить текущее состояние процесса перед отправкой сигнала.

2. Ошибка доступа к процессу

Еще одной проблемой, с которой можно столкнуться при отправке сигналов в ОС Windows, является ошибка доступа к процессу. Это может произойти, если у пользователя нет необходимых прав доступа или если процесс защищен от внешнего воздействия. Для решения этой проблемы необходимо проверить права доступа пользователя и убедиться, что процесс не защищен от отправки сигналов.

3. Периодические проблемы со связью

Время от времени могут возникать проблемы со связью при отправке сигналов в ОС Windows. Это может быть вызвано сетевыми проблемами, сбоями в программном обеспечении или другими факторами. Для решения этой проблемы необходимо проверить сетевое подключение, обновить программное обеспечение и перезапустить процесс, если необходимо.

Возможные проблемы и ошибки при отправке сигналов в ОС Windows могут быть разнообразными, но с правильным подходом и решением можно обеспечить бесперебойную работу программы или приложения. Важно быть внимательным к подробностям и следовать рекомендациям для успешной отправки сигналов в операционную систему Windows.

signal

The latest version of this topic can be found at signal.

Sets interrupt signal handling.

Do not use this method to shut down a Windows 8.x Store app, except in testing or debugging scenarios. Programmatic or UI ways to close a Windows 8.x Store app are not permitted according to Section 3.6 of the Windows 8 app certification requirements. For more information, see Application lifecycle (Windows Store apps).

Syntax

Parameters

func
Function to be executed. The first parameter is a signal value and the second parameter is a sub-code that can be used when the first parameter is SIGFPE.

Return Value

See errno, _doserrno, _sys_errlist, and _sys_nerr for more information about return codes.

Remarks

The signal function enables a process to choose one of several ways to handle an interrupt signal from the operating system. The sig argument is the interrupt to which signal responds; it must be one of the following manifest constants, which are defined in SIGNAL.H.

SIGINT is not supported for any Win32 application. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application, such as one in UNIX, to become multithreaded and cause unexpected behavior.

For floating-point exceptions, the value of func is not reset when the signal is received. To recover from floating-point exceptions, use try/except clauses to surround the floating point operations. It’s also possible to recover by using setjmp with longjmp. In either case, the calling process resumes execution and leaves the floating-point state of the process undefined.

If the signal handler returns, the calling process resumes execution immediately following the point at which it received the interrupt signal. This is true regardless of the kind of signal or operating mode.

Because signal-handler routines are usually called asynchronously when an interrupt occurs, your signal-handler function may get control when a run-time operation is incomplete and in an unknown state. The following list summarizes the restrictions that determine which functions you can use in your signal-handler routine.

Do not issue low-level or STDIO.H I/O routines (for example, printf or fread ).

Do not use any function that generates a system call (for example, _getcwd or time ).

Do not use any overlay routines.

A program must contain floating-point code if it is to trap the SIGFPE exception by using the function. If your program does not have floating-point code and requires the run-time library’s signal-handling code, just declare a volatile double and initialize it to zero:

Signal settings are not preserved in spawned processes that are created by calls to _exec or _spawn functions. The signal settings are reset to the default values in the new process.

Requirements

For additional compatibility information, see Compatibility.

Example

The following example shows how to use signal to add some custom behavior to the SIGABRT signal. For additional information about abort behavior, see _set_abort_behavior.

.NET Framework Equivalent

Источник

Send signal to process from command line

I read about signals and I know how to send a signal to a process from the command line. Just do

to know the pid of the process, and then

However, I’d like to find a more interactive and general way to do this if possible.

I’d like to send a signal to a specific process from the command line. I’d like to not need to print the PID of the process I want to signal, but rather use a way that the code understands which process should be signaled.

Other than that I’d like to understand exacly what the kill command does.

Картинка с сайта: sovet.driverlib.ru

Картинка с сайта: sovet.driverlib.ru

2 Answers 2

As far as I understood your question you want to signal a process by its name, not by its PID. This can easily be achieved by combining the two commands:

Does it kill the process that signals?

kill can kill. It doesn’t necessarily.

The command kill sends the specified signal to the specified processes or process groups.

That means, the kill command is used to **send any signal in general.

The SIGKILL signal is used to cause immediate program termination. It cannot be handled or ignored, and is therefore always fatal. It is also not possible to block this signal.

If a process receives the SIGKILL signal, it terminates immediately (no destructors called, no cleanup done). The only processes that do not terminate are uninterruptible processes.

A full list of signals available on Linux is found here.

I’d like to send a signal to a specific proccess from the command line. I’d like to not need to print the PID of the process I want to signal, but rather use a way that the code understands which process should be signaled.

Other than that I’d like to understand exacly what the kill command does.

Does it kill the process that signals?

It delivers the specified signal. That’s it. Some signals it can deliver will have the effect of killing the process.

Does it kill the process where it’s called?

It delivers a signal only to the process you specify.

If it kills a process it means that it’s similar to do exit(0), or does the process resume after the signal is sent back?

Источник

Практика работы с сигналами

Функция обработчик сигналов

Данная функция вызывается, когда процесс (или нить) получает неблокируемый сигнал. Дефолтный обработчик завершает наш процесс (нить). Но мы можем сами определить обработчики для интересующих нас сигналов. Следует очень осторожно относится к написанию обработчика сигналов, это не просто функция, выполняющаяся по коллбеку, происходит прерывание текущего потока выполнения без какой либо подготовительной работы, таким образом глобальные объекты могут находится в неконсистентном состоянии. Автор не берется приводить свод правил, так как сам их не знает, и призывает последовать совету Kobolog (надеюсь он не против, что я ссылаюсь на него) и изучить хотя бы вот этот материал FAQ.

Установить новый обработчик сигнала можно двумя функциями

Здесь мы установили наш обработчик для сигналов SIGUSR1 и SUGUSR2, а также указали, что необходимо блокировать эти же сигналы пока выполняется обработчик.
С обработчиком сигналов есть один не очень удобный момент, он устанавливается на весь процесс и все порожденные нити сразу. Мы не имеет возможность для каждой нити установить свой обработчик сигналов.
Но при этом следует понимать что когда сигнал адресуется процессу, обработчик вызывается именно для главной нити (представляющей процесс). Если же сигнал адресуется для нити, то обработчик вызывается из контекста этой нити. См пример 1.

Блокирование сигналов

Для того, чтобы заблокировать некоторый сигналы для процесса, необходимо добавить их в маску сигналов данного процесса. Для этого используется функция

Мы можем к уже существующей маске сигналов добавить новые сигналы (SIG_BLOCK), можем из этой маски убрать часть сигналов (SIG_UNBLOCK), а так же установить полностью нашу маску сигналов (SIG_SETMASK).
Для работы с маской сигналов внутри нити используется функция

которая позволяет сделать все тоже, но уже для каждой нити в отдельности.
Невозможно заблокировать сигналы SIGKILL или SIGSTOP при помощи этих функций. Попытки это сделать будут игнорироваться.

sigwait

Данная функция позволяет приостановить выполнении процесса (или нити) до получения нужного сигнала (или одного из маски сигналов). Особенностью этой функции является то, что при получении сигнала не будет вызвана функции обработчик сигнала. См. пример 2.

Посыл сигнала

Для того, чтобы послать сигнал процессу можно использовать две функции

С первой все понятно. Вторая нужна для того, чтобы послать сигнал самому себе, и по сути равносильна kill(getpid(), signal). Функция getpid() возвращает PID текущего процесса.
Для того, чтобы послать сигнал отдельной нити, используется функция

Пример использования сигналов

Все, что я описал выше, не дает ответа на вопрос «Зачем мне использовать сигналы». Теперь я хотел бы привести реальный пример использования сигналов и где без них попросту не обойтись.
Представьте, что вы хотите читать или писать какие-то данные в какое то устройство, но это может привести к блокированию. Ну например, чтение в случае работы с сокетами. Или может быть запись в пайп. Вы можете вынести это в отдельный поток, чтобы не блокировать основную работу. Но что делать когда вам нужно завершить приложение? Как корректно прервать блокирующую операцию IO? Можно было бы задавать таймаут, но это не очень хорошее решение. Для этого есть более удобные средства: функции pselect и ppoll. Разница между ними исключительно в юзабельности, поведение у них одинаковое. В первую очередь эти функции нужны для мультиплексирования работы с IO (select/poll). Префикс ‘p’ в начале функции указывает на то, что данная функция может быть корректно прервана сигналом.

Итак, сформулируем требование:
Необходимо разработать приложение, открывающее сокет (для простоты UDP) и выполняющее в потоке операцию чтения. Данное приложение должно корректно без задержек завершаться по требованию пользователя.
Функция треда выглядит вот так

Устанавливаем наш обработчик для SIGINT, и когда нужно завершить дочерний поток шлем ему этот сигнал.
Полный листинг см. пример 3.

На мой взгляд, недостатком данного способа является то, что в случае нескольких потоков мы можем завершить их только все сразу. Нет возможности устанавливать свой обработчик сигналов для каждого треда. Таким образом, нет возможности реализовать полноценное межпоточное взаимодействие через сигналы. Linux way это не предусматривает.

PS. Исходные коды разместил на сервисе PasteBin (ссылку не даю, а то еще за рекламу посчитают).
PPS. Прошу простить за обилие ошибок. Язык, слабая моя сторона. Спасибо, всем кто помог их исправить.

Данная статья не претендует на полное (и глубокое) описание работы с сигналами и нацелена в первую очередь на тех, кто до этого момента не сталкивались с понятием «сигнал». Для более глубоко понимания работы сигналов автор призывает обратиться в более компетентные источники и ознакомиться с конструктивной критикой в комментариях.

Источник

SignalObjectAndWait function (synchapi.h)

Signals one object and waits on another object as a single operation.

Syntax

Parameters

A handle to the object to be signaled. This object can be a semaphore, a mutex, or an event.

If the handle is a semaphore, the SEMAPHORE_MODIFY_STATE access right is required. If the handle is an event, the EVENT_MODIFY_STATE access right is required. If the handle is a mutex and the caller does not own the mutex, the function fails with ERROR_NOT_OWNER.

A handle to the object to wait on. The SYNCHRONIZE access right is required; for more information, see Synchronization Object Security and Access Rights. For a list of the object types whose handles you can specify, see the Remarks section.

The time-out interval, in milliseconds. The function returns if the interval elapses, even if the object’s state is nonsignaled and no completion or asynchronous procedure call (APC) objects are queued. If dwMilliseconds is zero, the function tests the object’s state, checks for queued completion routines or APCs, and returns immediately. If dwMilliseconds is INFINITE, the function’s time-out interval never elapses.

If this parameter is TRUE, the function returns when the system queues an I/O completion routine or APC function, and the thread calls the function. If FALSE, the function does not return, and the thread does not call the completion routine or APC function.

A completion routine is queued when the function call that queued the APC has completed. This function returns and the completion routine is called only if bAlertable is TRUE, and the calling thread is the thread that queued the APC.

Return value

If the function succeeds, the return value indicates the event that caused the function to return. It can be one of the following values.

Remarks

The SignalObjectAndWait function provides a more efficient way to signal one object and then wait on another compared to separate function calls such as SetEvent followed by WaitForSingleObject.

The SignalObjectAndWait function can wait for the following objects:

A thread can use the SignalObjectAndWait function to ensure that a worker thread is in a wait state before signaling an object. For example, a thread and a worker thread may use handles to event objects to synchronize their work. The thread executes code such as the following:

The worker thread executes code such as the following:

Note that the «signal» and «wait» are not guaranteed to be performed as an atomic operation. Threads executing on other processors can observe the signaled state of the first object before the thread calling SignalObjectAndWait begins its wait on the second object.

Use extreme caution when using SignalObjectAndWait and PulseEvent with WindowsВ 7, since using these APIs among multiple threads can cause an application to deadlock. Threads that are signaled by SignalObjectAndWait call PulseEvent to signal the waiting object of the SignalObjectAndWait call. In some circumstances, the caller of SignalObjectAndWait can’t receive signal state of the waiting object in time, causing a deadlock.

Use caution when using the wait functions and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. A thread that uses a wait function with no time-out interval may cause the system to become deadlocked. Two examples of code that indirectly creates windows are DDE and COM CoInitialize. Therefore, if you have a thread that creates windows, be sure to call SignalObjectAndWait from a different thread. If this is not possible, you can use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, but the functionality is not equivalent.

To compile an application that uses this function, define _WIN32_WINNT as 0x0400 or later. For more information, see Using the Windows Headers.

Источник

Передача файла сигналами

Добрый день, хабражители. Наверняка все знают что такое сигналы в Linux и для чего они нужны. Но сегодня, я хотел бы рассказать о, как мне кажется, нетрадиционном их применении.

Задача очень надуманная и направленна на тренировку своих навыков работы с сигналами и, немножко, побитовыми операциями. В общем, задача:
Программа должна порождать процесс, который посредством только сигналов передавал родителю файл, указанный в качестве аргумента командной строки. Родитель выводит полученный файл в stdout.

Решение очень простое: будем пользоваться сигналами, как азбукой морзе, только использоваться будт SIGUSR1 и SIGUSR2 вместо «Точка» и «Тире».

Решение

Будем передавать файл побитово, с помощью сигналов SIGUSR2 и SIGUSR1
Пускай SIGUSR2 — бит равный нулю, SIGUSR1 — бит равный единице.

Отправка данных

Читаем байт из файла в переменную с.
Создаем переменную counter равную 0b10000000 или 128.
Если c И (имеется в виду «побитовое и») counter равно единице, то старший бит равен единице, посылаем SIGUSR1, иначе посылаем SIGUSR2.
Делим counter пополам (получаем 0b01000000 или 64), то есть переходим ко второму слева биту.
Повторяем до тех пор, пока counter не станет равен нулю. Затем читаем новый байт из файла.

На языке Си это выглядит следующим образом:

Прием данных

Принимать мы будем в переменную out_char, изначально равную нулю.
Пока counter не равен нулю обрабатываем сигналы следующим образом:
Если пришел SIGUSR1, то out_char += counter, затем counter /= 2.
Если пришел SIGUSR1, то counter /= 2.

Напишем обработчики для сигналов:

Рабочий вариант

Теперь нужно рассмотреть случаи непредвиденной смерти родителя или ребёнка. Если умрет ребёнок, то всё просто — родитель получит SIGCHLD.

С ребёнком будет немного сложнее, нет гарантии что ребёнка как либо известят о смерти его родителя. Поэтому попросим ядро отправить нам SIGALRM, если никаких других сигналов нам не отправят через заданный промежуток времени. Добавим это в отправляющий цикл:

Добавим механизм подтверждения получения сигнала от ребёнка родителем. То есть, пока родитель не подтвердит получение бита, ребёнок передавать следующий не будет.

Делается это просто, в функции one и zero надо добавить отправку ответа. Будем отвечать сигналом SIGUSR1. После изменений функции будут выглядеть следующим образом:

А для ожидания ребёнком подтверждения добавим sigsuspend(&set):

Функция выполняемая при приходе от родителя сигнала подтверждения хоть и пустая, но должна быть, иначе будет выполняться действие для сигнала по-умолчанию — Выход.

Собственно функция и set:

В родителе же маска сигналов должна быть следующей:

Так как в процессе работы программы произойдет порождение нового процесса, который сразу же начнет слать нам сигналы (данные), sigprocmask(SIG_BLOCK, &set, NULL ) нужно сделать обязательно до fork’а, иначе есть шанс получить ошибку из-за эффекта гонки (race condition).
В итоге программа будет выглядеть так:

Исходный код программы можно скачать тут.

Вот так можно передавать файлы от одной программы другой, с помощью одних лишь сигналов. Правда такой подход мало эффективен и я не думаю, что ему есть применение в реальных проектах.

Источник