| |||
| БЕСПЛАТНАЯ ежедневная online лотерея! Выигрывай каждый день БЕСПЛАТНО! | |||
| |||
Synchronous and Overlapped Input and OutputThe ReadFile, WriteFile, TransactNamedPipe, and ConnectNamedPipe functions can run either synchronously or asynchronously. The ReadFileEx and WriteFileEx functions can run only asynchronously. When functions run synchronously, they do not return until the operation is finished. This means that the execution of the calling thread can be blocked for an indefinite period while it waits for a time-consuming operation to finish. When functions run asynchronously, they return immediately even before their operations are finished. This enables a time-consuming operation to be executed in the background while the calling thread is free to perform other tasks. Overlapped operations make it possible for one pipe to read and write data simultaneously and for a single thread to perform simultaneous I/O operations on multiple pipe handles. This enables a single-threaded server process to handle communications with multiple client processes efficiently. For examples that illustrate overlapped operations by a server process, see Server Using Overlapped Input and Output and Server Using Completion Routines. For a server process to use synchronous operations to communicate with more than one client, it must create a separate thread for each client process so that one or more threads can run while other threads are waiting. For an example of a multithreaded server process that uses synchronous operations, see Multithreaded Server. Overlapped operations on a named pipe are enabled by specifying the FILE_FLAG_OVERLAPPED flag when the handle is created (by the CreateNamedPipe function for a server process or the CreateFile function for a client process). If this flag is not specified, overlapped mode is disabled. The overlapped mode of a pipe handle cannot be changed after the pipe handle has been created. The overlapped mode can be different for server and client handles to the same pipe instance. The ReadFile, WriteFile, TransactNamedPipe, and ConnectNamedPipe functions can be performed asynchronously only if overlapped mode is enabled for the specified pipe handle and a valid pointer to an OVERLAPPED structure is specified. If the OVERLAPPED pointer is NULL, the function return value may incorrectly indicate that the operation completed. Therefore, it is strongly recommended that if you create a handle with FILE_FLAG_OVERLAPPED and want asynchronous behavior, you should always specify a valid OVERLAPPED structure or use the functions intended for asynchronous operations such as ReadFileEx and WriteFileEx. When ReadFile, WriteFile, TransactNamedPipe, and ConnectNamedPipe are performed asynchronously, one of the following outcomes occurs: · If the operation is complete when the function returns, the return value indicates the success or failure of the operation. If an error occurs, the return value is FALSE and the GetLastError function returns something other than ERROR_IO_PENDING. · If the operation has not finished when the function returns, the return value is FALSE and GetLastError returns ERROR_IO_PENDING. In this case, the calling thread must wait until the operation has finished. The calling thread must then call the GetOverlappedResult function to determine the results. The hEvent member of the specified OVERLAPPED structure must contain a handle to a manual-reset ѕ not an auto-reset ѕ event object. This is a synchronization object created by the CreateEvent function. The thread that initiates the overlapped operation uses the event object to determine when the operation is finished. For more information about event objects, see Synchronization. An event object is either in a signaled or nonsignaled state. If an overlapped function returns before its operation has finished, the system sets the state of the event object to nonsignaled. When the operation is finished, the system sets the state to signaled. The thread can detect the object's state by specifying a handle to the event object in a call to one of the wait functions. These functions do not return until the state of a specified object is signaled or until a time-out interval has elapsed. For the wait functions that wait for multiple objects, the function's return value indicates which of the objects is signaled. Doing this enables a server process to use a loop that performs the following steps: 1. Specify multiple event objects in a call to the wait function, then wait for one of the objects to be in a signaled state. 2. Use the wait function's return value to determine which overlapped operation is finished. 3. Perform the tasks necessary to clean up the completed operation and initiate the next operation for that pipe handle. This may involve starting another overlapped operation for the same pipe handle. If the hEvent member of the OVERLAPPED structure is a NULL pointer instead of a handle to an event object, the calling thread can use the pipe handle to determine when an overlapped operation has finished. In this case, the system sets the state of the pipe handle to signaled or nonsignaled, as described previously for the state of an event object. It is strongly recommended that you always use an event object when performing overlapped operations rather than relying on the pipe handle. In particular, you should not use the pipe handle for this purpose when performing simultaneous operations on the same handle because there is no way of knowing which operation's completion caused the pipe handle to be signaled. The only safe technique for performing simultaneous operations on the same pipe handle is to use a separate OVERLAPPED structure with its own event object for each operation. The ReadFileEx and WriteFileEx functions provide another form of overlapped I/O. Unlike the overlapped ReadFile and WriteFile functions, which use an event object to signal completion, the extended functions specify a completion routine. A completion routine is a function that is queued for execution when the read or write operation is finished. The completion routine is not executed until the thread that called ReadFileEx and WriteFileEx enters an alertable wait by calling one of the alertable wait functions: MsgWaitForMultipleObjectsEx. SignalObjectAndWait, WaitForSingleObjectEx, or WaitForMultipleObjectsEx. These functions are like the normal wait functions in that they return when a specified object is in the signaled state or when a time-out interval has elapsed. However, these functions can also perform an alertable wait that occurs when their fAlertable parameter is set to TRUE. In an alertable wait, the functions also return when a ReadFileEx or WriteFileEx completion routine is queued for execution. A server process can use the extended functions to perform a sequence of read and write operations for each client that connects to it. Each read or write operation in the sequence specifies a completion routine, and each completion routine initiates the next step in the sequence. | |||
| Пригласи друзей и счет твоего мобильника всегда будет положительным! | |||
| |||
| Пригласи друзей и счет твоего мобильника всегда будет положительным! | |||
Синхронный и Перекрытый Вклад и ВыходReadFile, WriteFile, TransactNamedPipe, И функции ConnectNamedPipe могут запустить или синхронно или асинхронно. ReadFileEx И функции WriteFileEx могут работать только асинхронно. Когда функции работают синхронно, они не возвращают пока действие не будет завершено. Это означает, что выполнение вызова резьбы может быть заблокировано на неопределенный период тогда как оно ждет трудоемкое действие, чтобы завершаться. Когда функции работают асинхронно, они возвращают немедленно даже прежде, чем свои действия будут завершены. Это приспосабливается трудоемкое действие, которое нужно выполняться на фоне тогда как вызывающая резьба свободна, чтобы выполнять другие задачи. Перекрытые операции делают возможным для одной трубы, чтобы читать и записывать данные одновременно и для единственной резьбы, чтобы выполнять одновременные операции В/В во многочисленных ручках трубы. Это позволяет единственный прошитый процесс сервера, чтобы оперировать связь со многочисленными процессами клиента эффективно. Для примеров, которые иллюстрируют перекрытые операции процессом сервера, смотри Сервер, использовавший Перекрытый Ввод и Выход и Сервер, использовавшие Программы Завершения. Для процесса сервера, чтобы использовать синхронные операции, чтобы связываться более чем с одним клиентом, это должно создать отдельную резьбу для каждого процесса клиента чтобы одна или более резьбы могут запустить тогда как другая резьба ожидается. Для примера multithreaded процесса сервера, который использует синхронные операции, смотри Сервер Multithreaded. Перекрытые операции в поименованной трубе приспособлены определением флага FILE_FLAG_OVERLAPPED когда ручка создана ( функцией CreateNamedPipe для процесса сервера или функция CreateFile для процесса клиента). Если этот флаг не определен, перекрывшее режим выведен из строя. Перекрытый режим ручки трубы не может быть измениться после того, как ручка трубы будет создана. Перекрытый режим может быть другим для сервера и клиент оперируется в тот же пример трубы. ReadFile, WriteFile, TransactNamedPipe, И функции ConnectNamedPipe могут выполняться асинхронно только если перекрытый режим приспособлен для определенной ручки трубы и правильный указатель в ПЕРЕКРЫТУЮ структуру определен. Если ПЕРЕКРЫТЫЙ указатель НЕДЕЙСТВИТЕЛЕН, функциональная обратная величина может неправильно указать, что операция завершала. Следовательно, сильно рекомендовано это если Вы создаете ручку с FILE_FLAG_OVERLAPPED и хотитесь асинхронное поведение, Вы должны всегда определить правильную ПЕРЕКРЫТУЮ структуру или использовать функции предназначенные для асинхронных операций как например, ReadFileEx и WriteFileEx. Когда ReadFile, WriteFile, TransactNamedPipe, и ConnectNamedPipe выполняются асинхронно, один из следующих результатов происходит: Если операция завершенна когда функция возвращается, обратная величина указывает успех или неудачу операции. Если ошибка происходит, обратная величина - ЛОЖЬ и функциональный возврат GetLastError что-то кроме ERROR_IO_PENDING. Если операция не завершилась бы когда функция возвращается, обратная величина - ЛОЖЬ и возврат GetLastError ERROR_IO_PENDING. В этом случае, вызов резьбы должен ожидаться пока операция не завершилась. Вызов резьбы должен затем называть функцию GetOverlappedResult, чтобы определять результаты. Элемент hEvent определенной ПЕРЕКРЫТОЙ структуры должен содержать ручку в руководство-восстановленное U не авто-восстановленное U объект события. Это - объект синхронизации созданный функцией CreateEvent. Резьба, которая вводит перекрытую операцию использует объект события против определяться когда операция завершена. Более подробно об объектах события, смотри Синхронизацию. Объект события - или в сигнальном или nonsignaled состоянии. Если перекрытая функция возвращается прежде, чем операция завершилась, система устанавливает состояние объекта события против nonsignaled. Когда операция завершена, система устанавливает состояние на сигнализированное. Резьба может обнаружить объектное состояние определяя ручку на объект события на вызове в одну из функций ожидания. Эти функции не возвращаются пока состояние определенного объекта не будет сигнализировано или пока интервал задержки не прошел. Для функций ожидания, которые ждут многочисленные объекты, функциональная обратная величина указывает который из объектов сигнализированы. Занятие это допустимые процесс сервера, чтобы использовать цикл, который выполняет следующее шагов: 1. Определите многочисленные объекты события на вызове в функцию ожидания затем ждите один из объектов против быть в сигнальном состоянии. 2. Используйте функциональную обратную величину ожидания, чтобы определять, который перекрывшее операцию завершен. 3. Выполните задачи необходимые наводить порядок полный такт работы и вводить следующую операцию для этой ручки трубы. Это может включить запуск другое перекрывшее операцию для той же ручки трубы. Если элемент hEvent ПЕРЕКРЫТОЙ структуры является НЕДЕЙСТВИТЕЛЬНЫМ указателем вместо ручки на объект события, вызов резьбы может использовать ручку трубы, чтобы определяться когда перекрытая операция завершилась. В этом случае, система устанавливает состояние ручки трубы на сигнализированное или nonsignaled, как описано прежде для состояния объекта события. Сильно рекомендовано, чтобы Вы всегда использовали объекту события при дрессированных перекрытых операциях а не доверять в ручке трубы. В конкретном, вам не следует использовать ручку трубы с этой целью при дрессированных одновременных операциях в той же ручке поскольку нет пути знающей какой операции завершения заставлял ручку трубы, чтобы быть сигнализированн. Единственная безопасная техника для дрессированных одновременных операций в той же ручке трубы должна использовать отдельную ПЕРЕКРЫТУЮ структуру со своим собственным объектом события для каждой операции. ReadFileEx И функции WriteFileEx обеспечивают другую форму перекрытого В/В. В отличие от перекрытых ReadFile и функций WriteFile, которые используют объект события против сигнального завершения, расширенные функции определяют программу завершения. Программа завершения является функцией, которая поставлена в очередь для выполнения когда чтение или операция записи завершены. Программа завершения не выполнена до резьбы, что назвавшее ReadFileEx и WriteFileEx вводит ожидание alertable вызывая одну из функций ожидания alertable: MsgWaitForMultipleObjectsEx. SignalObjectAndWait, WaitForSingleObjectEx, ИЛИ WaitForMultipleObjectsEx. Эти функции похожий нормальное ожидание функционирует в котором они возвращают когда определенный объект - в сигнальном состоянии или когда интервал задержки прошел. Тем не менее, эти функции могут также выполнить ожидание alertable, которое происходит когда их параметр fAlertable установлен в ИСТИНУ. В ожидании alertable, функции также возвращаются когда ReadFileEx или программа завершения WriteFileEx поставлена в очередь для выполнения. Процесс сервера может использовать расширенные функции, чтобы выполнять последовательность чтения и записывать операции для каждого клиента, который подключает к этому. Каждый был прочитан или операция записи в последовательности определяет программу завершения, и каждая программа завершения вводит следующий шаг в последовательность. | |||
| |||
 |
