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

_FR>>>Если "остановка прослушивания" — штатная операция (а иначе и быть не может, ибо к остановке приводит явный вызов), то нет ничего страшного в том, что бы хранить специальный флаг, сообщающий о том, "остановлена ли прослушка".
J>>…Вот только флагом (булевской переменной) здесь не обойтись. По крайней мере, я не вижу как это сделать?

private bool timerAborted = false;

Во-первых Вы забыли volatile

Во-вторых, какой-нибудь вызов OnTimer() уже может начать исполняться к моменту выхода из using'а, пройти проверку флага, но ещё не дойти до evt.Set() И тогда опять-таки всё может сдохнуть...

Ещё раз повторяю, тут нужен нормальный семафор/событие. Плюс посмотреть как работает этот Timer по части наличия/логики очереди отложенных вызовов OnTimer()

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

J>Сразу после отправки сообщения, допер как сделать баг 100% воспроизводимым.
J>Достаточно эмулировать переключение контекста сразу после проверки флага в колбеке. Вот так:


Точно, я ошибся И всё из-за того, что сам не редко критикую: лень.
Надо было добавить критическую секцию так вот:

  class Test
  {
    private Timer timer;
    private AutoResetEvent evt;
    private bool timerAborted = false;
    private readonly object TimerAbortedSyncRoot = new object();

    public void RunTest() {
      TimerCallback callback = state => {
        try {
          if(!timerAborted) {
            lock(TimerAbortedSyncRoot) {
              if(!timerAborted) {
                evt.Set();
              }//if
            }//lock
          }//if
        } catch(ObjectDisposedException ex) {
          Console.WriteLine("Exception: {0}", ex);
        }//try
      };

      using(evt = new AutoResetEvent(false))
      using(timer = new Timer(callback, null, 1, 0)) {
        evt.WaitOne(1, false);
        lock(TimerAbortedSyncRoot) {
          timerAborted = true;
          evt.Close(); // И закрываем из-под лока
        }//lock
      }//using
    }

    …
  }

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

_FR>Точно, я ошибся И всё из-за того, что сам не редко критикую: лень.
_FR>Надо было добавить критическую секцию так вот:

А ни убивает ли это саму идею асинхронного исполнения на корню?

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

D>Ещё раз повторяю, тут нужен нормальный семафор/событие. Плюс посмотреть как работает этот Timer по части наличия/логики очереди отложенных вызовов OnTimer()

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

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

M>Если Вы раньше писали на С++, то обязательно прочтите это.

Спасибо, очень познавательная дока

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

_FR>>Точно, я ошибся И всё из-за того, что сам не редко критикую: лень.
_FR>>Надо было добавить критическую секцию так вот:

J>А ни убивает ли это саму идею асинхронного исполнения на корню?

Почему? Wait-то не в локе. Лочится лишь установка флага и сброс эвента.

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

_FR>Почему? Wait-то не в локе. Лочится лишь установка флага и сброс эвента.

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

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

PD>Не знаю, есть ли это в .Net, но снятие асинхронного запроса в Win32 есть — CancelIO.

Мы покамест только достаточно простые ситуации разбираем Закрытие того же сокета, например, автоматически cancel'ит все I/O запросы к нему, включая асинхронные.

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

_FR>>Почему? Wait-то не в локе. Лочится лишь установка флага и сброс эвента.

J>Ну, на каждый тик таймера мы должны лочиться, что само по-себе неприятно. Конечно, в нормальной ситуации,
J>никто с нами за этот лок не конкурирует, поэтому оверхед небольшой. Но все же он есть ...
J>

Ну уж если критическая секция "убивает … саму идею асинхронного исполнения на корню"… Помойму как раз для этого они и были сделаны. Нет?

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

D>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Не знаю, есть ли это в .Net, но снятие асинхронного запроса в Win32 есть — CancelIO.

D>Мы покамест только достаточно простые ситуации разбираем Закрытие того же сокета, например, автоматически cancel'ит все I/O запросы к нему, включая асинхронные.

И ждет завершения всех запущенных колбеков? Если нет, то все проблемы остаются. А MSDN, как всегда, все эти тонкости скромно умалчивает

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

_FR>Ну уж если критическая секция "убивает … саму идею асинхронного исполнения на корню"… Помойму как раз для этого они и были сделаны. Нет?

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

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

_FR>Надо было добавить критическую секцию так вот:

Уже лучше. Осталось решить последнюю проблему: потоки из пула это background-потоки

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

_FR>>Надо было добавить критическую секцию так вот:
D>Уже лучше. Осталось решить последнюю проблему: потоки из пула это background-потоки

И в чём их особенность в данном случае…?

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

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

А Вы бы показали нам грешным что да как, да научили бы ...

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

_FR>>Ну уж если критическая секция "убивает … саму идею асинхронного исполнения на корню"… Помойму как раз для этого они и были сделаны. Нет?

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

В идеальной программе вообще ничего не надо знать о существовании многопоточности

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

D>>Мы покамест только достаточно простые ситуации разбираем Закрытие того же сокета, например, автоматически cancel'ит все I/O запросы к нему, включая асинхронные.
J>И ждет завершения всех запущенных колбеков? Если нет, то все проблемы остаются.

Дык а почему она должна их ждать ? Это ведь асинхронное I/O, в том и суть, что никто ничего не блокирует.

J>А MSDN, как всегда, все эти тонкости скромно умалчивает

MSDN большой Вы просто не там смотрите. В описании closesocket(), например, всё написано достаточно чётко:

An application should not assume that any outstanding I/O operations on a socket will all be guaranteed to completed when closesocket returns. The closesocket function will initiate cancellation on the outstanding I/O operations, but that does not mean that an application will receive I/O completion for these I/O operations by the time the closesocket function returns. Thus, an application should not cleanup any resources (WSAOVERLAPPED structures, for example) referenced by the outstanding I/O requests until the I/O requests are indeed completed.

...и т.д.

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

D>MSDN большой Вы просто не там смотрите.

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

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

D>>Уже лучше. Осталось решить последнюю проблему: потоки из пула это background-потоки
_FR>И в чём их особенность в данном случае…?

В том же что и всегда: их пристреливают на месте, как только все не-background завершаются. А уважаемый jedi хочет гарантированной полной отработки всех запущенных callback'ов.

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

D>>>Уже лучше. Осталось решить последнюю проблему: потоки из пула это background-потоки
_FR>>И в чём их особенность в данном случае…?
D>В том же что и всегда: их пристреливают на месте, как только все не-background завершаются. А уважаемый jedi хочет гарантированной полной отработки всех запущенных callback'ов.

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

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

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

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