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

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

_>>ага! каждая новая overlapped будет увеличивать счетчик, а ее удаление будет уменьшать. останется только потокобезопасность предусмотреть.

MC>InterlockedIncrement/InterlockedDecrement, например.

да. точно! спасибо.

_>>что же получается — после закрытия handle удалять объект, если ссылок на него больше нет.

MC>Нет, не удалять, а уменьшать счетчик на единицу. Счетчик при создании ставить в 1.

ээ.. а если счетчик уже равен 0, то оставлять что ли? если ссылок больше нет, то при закрытии сокета что еще делать остается?

_>>а если есть, то оставить на откуп потоку в IOCP, чтобы последняя OVERLAPPED операция проверила счетчик и удалила?

MC>Не последняя. Перед началом любой операции увеличиваешь счетчик, по поступлению уведомления уменьшаешь. По достижению счетчиком нуля удаляешь объект. Специальный случай — невозможность начать операцию (вызов I/O вернул ошибку, и код ошибки не IO_PENDING). В этом случае надо уменьшить счетчик сразу, т.к. уведомления не будет.

получается, что удаление объекта возможно в двух местах (мы ведь не исключаем, что сокет может быть создан, связан с IOCP, но никаких отложенных операций на нем в данный момент нет), а именно: изнутри потока, управляемого IOCP и из потока, который закрывает сокет.

_>>или вообще периодически пробегать по списку handle и чистить?

MC>Не, это некрасиво.