Re: Когда может возникнуть ситуация, что rev->instance != instance?

[megalodon]

Пытаюсь вникнуть в мысль: "Мы могли закрыть соединение до того, как
добрались до обработки событий". Но где в промежутке между epoll_wait() и
итерацией цикла, в которой мы обрабатываем событие то место, где мы можем
потенциально закрыть сокет?

    events = epoll_wait(ep, event_list, (int) nevents, timer);

    err = (events == -1) ? ngx_errno : 0;

    if (flags & NGX_UPDATE_TIME || ngx_event_timer_alarm) {
        ngx_time_update();
    }

    if (err) {
    .....
    }

    if (events == 0) {
       .....
    }

    ngx_mutex_lock(ngx_posted_events_mutex);

    for (i = 0; i < events; i++) {
        c = event_list[i].data.ptr;

        instance = (uintptr_t) c & 1;
        c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);

        rev = c->read;

        if (c->fd == -1 || rev->instance != instance) {

Если c->fd не равно -1 и если  rev->instance не совпадает с instance, то
получается, что где-то между строками    
 events = epoll_wait(ep, event_list, (int) nevents, timer);   и   
   .....
 if (c->fd == -1 || rev->instance != instance) { 
произошло инвертирование этого поля?


"Несоответствие instance возможно, когда мы уже закрыли соединение, про
которое нам сообщает ядро." Получается, что пока процесс спал, будучи
заблокированным на шаге epoll_wait(), каким-то образом сокет закрылся и
структура ngx_connection_t была использована повторно, но как, ведь процесс
был заблокирован?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,243182,243215#msg-243215