Здравствуйте, jedi, Вы писали:

_FR>>Мне казалось, наоборот, надо отсечь (и не обрабатывать) колбеки, вызванные после наступления некоего события под условным названием "отмена запроса".

J>Скорее так: я хочу чтоб Close() подождал окнчания уже заупущенных колбеков и гарантировал, что не будет новых.

Это протеворечит

…я хочу остановить сервер и отменить прослушку.

(здесь

Автор: jedi
Дата: 19.09.08

)

А как подождать завершения подсказали в первом же ответе

Здравствуйте, jedi, Вы писали:

D>>Уже лучше. Осталось решить последнюю проблему: потоки из пула это background-потоки
J>А Вы бы показали нам грешным что да как, да научили бы ...

Дык я уже ведь говорил, что в случае Timer'а надо его внутреннее устройство знать. А смотреть лень
Вот про сокеты код есть, но он проприетарный, большой, и непонятный. Проще заново написать, а я в отпуске... Может попробую завтра накидать примерчик

Здравствуйте, _FRED_, Вы писали:

_FR>А как подождать завершения подсказали в первом же ответе

Так вот подсказали неправильно. AsyncWaitHandle.WaitOne() ожидает завершение/отмену асинхронного вызова, AcceptEx() в данном случае, а не callback'а запускаемого после него.

Здравствуйте, drol, Вы писали:

_FR>>А как подождать завершения подсказали в первом же ответе

D>Так вот подсказали неправильно. AsyncWaitHandle.WaitOne() ожидает завершение/отмену асинхронного вызова, AcceptEx() в данном случае, а не callback'а запускаемого после него.

Ну ОК, тогда EndInvoke можно позвать. Или, если EndInvoke по каким-либо соображениям не устраивает, завести свой объект синхронизации, который выставлять при завершении. Сути это не меняет, главное, что принципиально осуществимо.

Здравствуйте, jedi, Вы писали:

J>Всем привет.

J>Изучаю .NET, возникают вопросы .
J>В частности, не совсем понятно как решается проблема отмены асинхронных вызовов.
J>К примеру, у меня есть слушающий сокет, которому я сказал BeginAccept.
J>В какой-то момент, я решаю остановить прослушивание и вызываю socket.Close().
J>Что произойдет, если как раз в этот момент исполняется код из accept callback-а?
J>Ведь он может обращаться к объектам которые уже disposed, верно?

J>Следущий код, демонстрирует проблему (на примере таймера):

Запустил я у себя этот пример, никакой проблемы не обнаружил. Что я не привильно сделал ? Или может быть он не достаточно долго проработал ? В течении 10 мин полет нормальный.

Здравствуйте, Гор, Вы писали:

Гор>Запустил я у себя этот пример, никакой проблемы не обнаружил. Что я не привильно сделал ?

Не прочитал всю ветку, перед тем как задавать глупые вопросы.

Здравствуйте, jedi, Вы писали:

J>Приступая к изучению .NET, я оджидал, что он облегчит мне жизнь, а не усложнит или оставит все как есть ...

На всей планете программистов знающих что такое асинхронное I/O от силы доли процента. А уж из тех кто на .NET/Java работает так и вообще. High Performance I/O весьма экзотическая область, мэйнстрим вовсе не там.

*А Вы вот возьмите, да напишите сами красивую либу

J>К тому же Вы сейчас привязались к конкретной реализации (MS.NET). Обстоят дела также в случае того же Mono?

Mono это ваши личные проблемы Стандарты связанные с .NET соответствующие библиотеки никак не покрывают, насколько я в курсе. И Microsoft насчёт не своих платформ ничего не обещала...

Здравствуйте, drol, Вы писали:

D>На всей планете программистов знающих что такое асинхронное I/O от силы доли процента. А уж из тех кто на .NET/Java работает так и вообще. High Performance I/O весьма экзотическая область, мэйнстрим вовсе не там.

Я не думаю, что все так печально. Ничего сакрального в асинхронном вводе-выводе нет.

D>*А Вы вот возьмите, да напишите сами красивую либу

Да я как бы губу раскатал, что уже написано до меня .
Я наверное еще поищу, почитаю что умные люди пишут. Может кто из местных корифеев подтянется к обсуждению
и просветит меня.

Вообще, мне .нет по работе сейчас на фиг не нужен (я пишу на плюсах). Это скорее развлечение —
потыкать в него, посмотреть что к чему, может понравится и проникнусь. А может и плюну через время