@squirrel *sometimes*, calling `close()` on the accept socket is good enough - either from a signal handler or from code linked to one of your other sockets. Cross-thread close() (actually, cross-thread sockets) are full of pain though.
I've had success in the past with libev to hide all the scar stuff. Multiple threads can happen elsewhere.
@lupine i tried both close() and shutdown() from a SIGINT handler and neither unblocked accept() and now i'm trying to understand select() but it's really confusing
@squirrel I feel your pain.
You can get the call to `select()` to return when either of the following is true:
* a signal was received
* a new connection is made to your server socket
You need the accept()ing socket to be non-blocking though, because linux.
Also make sure you're using exceptfds as well as readfds
*vietnam-style flashbacks, cut to a slightly hairy man rocking to himself in the corner of a dimly-lit room*
@lupine i mean if i make the accept non-blocking i won't need select anyway...
but then it's running a while loop forever and eating CPU
@squirrel right, that's why you need select(). So you're not busy-waiting and burnong a whole core on `if err == EAGAIN`
@lupine hmm
i'm afraid i'm still not following how i'm supposed to factor select into the code i have right now :(
every example of select i've found online looks incredibly complicated and it all flies over my head
@squirrel somewhere you have a `while() { accept() }`
That needs to change to `while { select() }`
select will tell you when to exit the program, and when to call `accept()`
but even when `select()` tells you to call `accept()`, `accept()` may block, preventing the next go-around to select() (and the exit-signal logic). So that socket *has* to be non-blocking.
fdsets are wicked annoying, as is getting the signal handler to cause an fd to become readable (so it can go in select).
@squirrel happy to poke a gist with a stick if it'll help you?
@lupine oh, heck, i think i managed to figure it out actually!
@squirrel show!