maple classic™ 
good hecking lord i am servos deep in c code and i'm actually slightly enjoying myself that i made a pure telnet chat server work?
i just need to figure out how to make it quit properly now because it gets stuck in the main loop waiting on accept() and i can't seem to unblock it from that
@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 happy to poke a gist with a stick if it'll help you?
@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
@lupine oh, heck, i think i managed to figure it out actually!
@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 actually i have a while(running) which calls accept() inside it
my main issue is i'm not sure how to setup select or what to expect from it and the man page is very confusing
@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).