Hi Pablo, I have had a look at your new alarm.c. I have a few questions about it: - Please explain why you now have 2048 (!) alarm queues, where the correct one is determined by hashing the alarm struct. I fail to imagine how this hashing might be useful. I can only see that it makes the code more complex and 2048 times slower - except for add_alarm(), which becomes a little bit faster, but there are only few add_alarm() invocations compared with get_next_alarm_run() and do_alarm_run(). - __run() is again bugged regarding due alarms: when an alarm is due, all readied file descriptors are ignored (l 193). This is automatically recovered in the next select() call, so you didn't notice it. Why do you keep screwing up this piece of code over and over? ;-) - why this overcomplicated new __run() prototype with an int pointer parameter? Its returned value is never used. Its input value is only used to set next_alarm to NULL - why not just pass NULL as next_alarm in the first place (my patches did exactly that)? Why does __run() have a return value? Max - To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
