I installed some code that one of this forum's member's wrote and so far have had no trouble with it except one. This bug message:
Log: [*****] BUG: ALARM CLOCK! In section new_descriptor: after accept
What this post is about is, I'm a noob coder (if it's not obvious) and was wondering what are some possible causes for that lag alarm bug message written into the SMAUG code to activate? (don't reply "lag" please hehe)
To avoid being too vague, what the code does is add the old function that allows sending color to a descriptor so I can have color on the greeting. Nopey flavor.
If no one replies no problem I'll probably figure it out, just figured there was probably enough code knowledge roaming around to find out here.
I dunno how much you understand whats going on here, but heres an overview that may indicate the problem or at least attempt to help... I'm afriad I'm not fully up on the Smaugish code, I tend to be a bit more generic
Anywho, some background first.
The alarm is simply where a SIGALRM is raised and caught using signal handlers. There is a function called alarm() in unistd.h that allows you to define a number of seconds to count down from and once that time period is up, the alarm signal is raised. Using signal() from signal.h you can assign a custom handler to specific signals, Smaug attaches its custom alarm handler to the SIGALRM and sets the timer in the main game_loop (or at least somewhere which happens regullary). If you DON'T reach the next alarm call in the loop it never resets, the alarm goes off and the signal fires logding a bug saying its lagging. This means whatever section it indicates its in is taking essentially, too long. A common cause of this can be DNS reverse lookups while ppl login without a seperate DNS slave process, as some DNS lookups can take time, or simply require time to timeout.
In essence, the whole process of accepting a new_descriptor (after accept) it appears is taking too long, you can find out how long it has by taking a look for the alarm() function call in your game_loop, (it might be a setitimer call though, depending on what the author was intending and which type of clock they wanted to use)
A word of warning, you may have noticed where its setting the char* that its using to output in that alarm clock bug report, the fewer of those there are, the less accurate any bug report will be on where the problem is occuring (as it just tells you where the alarm went off, anything before it after the last alarm() call could have caused the slow down really). Its possible all the colour parsing is causing it to slow down, but somehow I very much doubt it, unless you are talking a HUGE amount of text, processing a text string to insert ANSI sequences isn't exactly taxing and time comsuming (although admittedly I don't know the granularity on the alarm periods you have, or even the ones Smaug has), but you may want to take a look at how long it takes to accept a new connection.
I could suggest use of some profiling tools (like gprof from the GNU kit) and/or strace to look at the system calls so you can see exactly whats going on, but I'm not very experienced in the use of them yet, so I'm not entirely sure if they'd help or hinder at this stage
Hopefully that helps, oh and one other point, Network Lag has NOTHING to do with this, select() it is intelligent enough to know if a input/output action will block and thats the point of having the fd_sets pass through it, if there is nothing on the socket, then there is nothing on the socket, its not like you have to wait for it to do stuff, thats what the system/OS/kernel does underneath you