EpollSelector: Keys must be removed from associative array on error in register

Do you have any suggested patches for these tickets?

There's a patch for the basic fix.

It doesn't address the suggested possibility for retrying failed calls to epoll_ctl(, CTL_MOD, , ) as epoll_ctl(, CTL_ADD, , ) instead. This would still need to be done by the user of the EpollSelector? class upon catching an exception thrown by register().

Ok I'm having a look at this issue now, and have modified EpollSelector?.register to remove the key from the associative array in cases where CTL_MOD fails, and to retry failed CTL_MODs as CTL_ADDs, and vice versa.

Here's a small test which demonstrates the problem of a CTL_MOD failing.

import tango.io.selector.EpollSelector;
import tango.net.device.Socket;
import tango.io.Stdout;

void main ( )
{
    // Open a socket
    auto s = new Socket;
    s.connect("test.com", 80);
    Stdout.formatln("Socket fd = {}", s.fileHandle);

    // Create an EpollSelector and register the socket with it
    auto e = new EpollSelector;
    e.open;
    e.register(s, Event.Write);

    // Close the socket. The fileHandle is automatically removed from epoll, but it still
    // exists in the associative array in the EpollSelector.
    s.shutdown;
    s.native.reopen;

    // Open the socket again and try to re-register it (note: fileHandle is the same as before)
    s.connect("test.com", 80);
    Stdout.formatln("Socket fd = {}", s.fileHandle);

    try
    {
        // Because the fileHandle is already in the associative array in the selector,
        // e.register thinks it's modifying an already registered key, and thus calls
        // epoll_ctl(, EPOLL_CTL_MOD, , ), which now fails, as the key is actually not
        // registered with epoll.
        e.register(s, Event.Write);
        Stdout.formatln("Test was successful");
    }
    catch ( Exception e )
    {
        Stdout.formatln("Register exception: {}", e.msg);
        Stdout.formatln("Test failed");
    }
}

I'll upload the patch shortly, and am going to continue testing to confirm that no unexpected behaviour results from these changes.

I've been running various different epoll-intensive projects with this patch for several months now, and haven't come across any issues, so I'd suggest the patch be applied to trunk now.