Не едут лыжи к вечеру .. не вижу очевидного .. ткните носом ?

← →
Digitman © (2004-11-18 16:04) [0]

Cитуация (куда уж проще):

1. Делаю попытку коннекта к заведомо существующему "слущающему" экз-ру именованного пайпа

hPipe := CreateFile(имя_пайпа,
режим_доступа, 0, nil,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, FILE_FLAG_OVERLAPPED);

результат : hPipe <> 0, т.е. вызов успешен, и я получил рукоятку к пайпу, который далее я намерен использовать для неблокирующих операций ввода/вывода (с указанием корректной overlapped-структуры)

2. Готовлю overlapped-структуру

FillChar(ovr, sizeof(ovr), 0); //обнулил структуру в соотв. с док-цией
ovr.hEvent := CreateEvent(nil, False, False, nil);

результат : ovr.hEvent <> 0, т.е. ивент гарантированно создан, и его рукоятка вписана как положено в соотв.поле структуры

3. Стартую собссно операцию ввода, ожидая в соответствии с док-цией неблокирующее выполнение нижеслед.вызова :

FPendingRead := ReadFileEx(hPipe, адрес_буфера_чтения, ожидаемый_размер, @ovr, корректный_адрес_подпрограммы_завершения);

результат : вызванная мной ф-ция ReadFileEx() исполняется в блок.режиме.

Вопрос :

где ж я лыжи-то не смазал ?

← →
Dmitriy O. © (2004-11-18 16:13) [1]

А кто такой "Пайп" ?

← →
clickmaker © (2004-11-18 16:14) [2]

> Digitman © (18.11.04 16:04)

А зачем тебе ивент с рукояткой? Ведь если верить msdn, то

The ReadFileEx function ignores the OVERLAPPED structure"s hEvent member. An application is free to use that member for its own purposes in the context of a ReadFileEx call. ReadFileEx signals completion of its read operation by calling, or queuing a call to, the completion routine pointed to by lpCompletionRoutine, so it does not need an event handle

← →
Игорь Шевченко © (2004-11-18 16:20) [3]

Digitman © (18.11.04 16:04)

А сам Pipe у тебя создан с флажком FILE_FLAG_OVERLAPPED при вызове CreateNamedPipe ?

← →
Странник © (2004-11-18 16:23) [4]

> Digitman
Давненько дело было, и под рукой нет.
Но если по памяти, вроде к FILE_FLAG_OVERLAPPED еще какой-то флаг по OR прикрутить надо.

← →
Digitman © (2004-11-18 16:35) [5]

> Dmitriy O. © (18.11.04 16:13) [1]
> кто такой "Пайп" ?

Эт, брат, такая хитрая хреновина, которая тебя уж никак не должна заботить, пока не наведешь в своей голове порядок с Автошемой. И с SQL до кучи.

> clickmaker © (18.11.04 16:14) [2]
> А зачем тебе ивент с рукояткой?

а блажь у меня !
желаю, понимаешь ли, в теле п/п завершения взвести ивент в сигналящее состояние. Что-то мешает мне сделать это ? думаю - нет.

> Игорь Шевченко © (18.11.04 16:20) [3]
> А сам Pipe у тебя создан с флажком FILE_FLAG_OVERLAPPED
> при вызове CreateNamedPipe ?

Всенепременно.
Серверная сторона тоже использует неблок.ввод/вывод.
И после успешного ConnectNamedPipe на серв.стороне я точно так же вызываю ReadFileEx, который завершается ожидаемым образом, т.е. исполняется в неблок.режиме, возвращая мне "вожделенное" True.

а, спрашивается, серв.сторона тут с какого боку припека ?
каждая из сторон, думаю, вправе решать индивидуально. блок.транспорт ей нужен или неблокирующий ... разве не так ?

← →
Игорь Шевченко © (2004-11-18 16:42) [6]

попробуй CreateEvent (nil, True, False, nil)

"The ReadFile, WriteFile, TransactNamedPipe, and ConnectNamedPipe functions can be performed asynchronously only if you enable overlapped mode for the specified pipe handle and specify a valid pointer to an OVERLAPPED structure. If the OVERLAPPED pointer is NULL, the function return value can incorrectly indicate that the operation has been 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.

The hEvent member of the specified OVERLAPPED structure must contain a handle to a manual-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 has finished. You should not use the pipe handle for synchronization 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 reliable 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."

← →
Digitman © (2004-11-18 16:51) [7]

> Игорь Шевченко © (18.11.04 16:42) [6]

> попробуй CreateEvent (nil, True, False, nil)

Игорь, роли это не играет (проверено на все сто), да и не понимаю, каким образом опция ручного или автом.сброса, заданная прри создании ивента, может влиять на ситуацию. Я вправе и сам, "ручками", сбрасывать ивент и положиться на автосброс Wait-вызовом.

← →
clickmaker © (2004-11-18 17:14) [8]

PIPE_WAIT часом нигде не стоит?

← →
Digitman © (2004-11-18 17:22) [9]

> clickmaker © (18.11.04 17:14) [8]

стоит.
на серв.стороне.
на той самой стороне, где с ReadFileEx() при этой опции нет никаких проблем - ф-ция, как и ожидается, использует overlapped mode и исполняется асинхронно, немедленно возвращая True.

и как это вяжется с клиентской стороной ? на которой никаких PIPE_WAIT и в помине нет как опции создаваемого пайпа ?

вот уж воистину "Стою на асфальте я в лыжи обутый ..")

с утречка на свежий взгляд обнаружилась совершенно дурацкая ошибка :

не

hPipe := CreateFile(имя_пайпа,
режим_доступа, 0, nil,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, FILE_FLAG_OVERLAPPED);

а

hPipe := CreateFile(имя_пайпа,
режим_доступа, 0, nil,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL or FILE_FLAG_OVERLAPPED, 0);

Да, лыжи в порядке 8)
Я тут вместо OR написал AND - потратил почти час. Личный рекорд - не ждал такой идиотской ошибки 8)

> Digitman © (18.11.04 16:35) [5]
> > Dmitriy O. © (18.11.04 16:13) [1]
> > кто такой "Пайп" ?
> Эт, брат, такая хитрая хреновина, которая тебя уж никак
> не должна заботить, пока не наведешь в своей голове порядок
> с Автошемой. И с SQL до кучи.
И мне, уважаемый мастер, можно сказать что такое пайп? Ну и заодно что у меня не в порядке с головой? :-)

RTFM, батенька, RTFM :)
Pipes
A pipe is a communication conduit with two ends; a process with a handle to one end can communicate with a process having a handle to the other end. This overview describes how to create, manage, and use pipes.
Далее по файлу Win32.hlp

Не едут лыжи к вечеру .. не вижу очевидного .. ткните носом ? Найти похожие ветки