@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).
@lupine sure here you go https://gist.github.com/Lana-chan/deea588d5673fdac0ebd89c5643aaa8b
it's fully functional atm, but accept is non-blocking and consumes lots of cpu
@squirrel show!
@squirrel consider https://gist.github.com/lupine/7d76469da0112d84886610429c53d66e
We make the signal handler write to a pipe, the read side of which goes into select()
We make select() wait indefinitely for either the accept fd or the signal_shutdown fd to be readable
if the signal_shutdown fd is the readable one, we exit. if it's the accept one, we try to do an accept(), and loop if that fails, as it may under linux.
Still, nowt works when a client is connected.
@lupine hahaahah mine is so much less polished
i just wait for activity on 'acc' socket
https://gist.github.com/Lana-chan/deea588d5673fdac0ebd89c5643aaa8b
@squirrel that works too! This is all decades of cruft, piled one hack atop the other, so it doesn't exactly need to be polished :D
@lupine what do you mean?
@squirrel sockets programming and the UNIX standard generally. None of it reallt fits together well, and corret code is invariably messy code.
@lupine ahh okay. this is was just hastily written for a uni course i need to turn in in a couple of days so as long as normal operation works i don't really mind if it's not the perfectly "proper" way to handle things, i guess
@lupine oh, heck, i think i managed to figure it out actually!