View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001804 | unreal | documentation | public | 2004-05-11 00:24 | 2004-05-11 11:22 |
| Reporter | fez | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Product Version | 3.2 | ||||
| Summary | 0001804: select | ||||
| Description | despite my overall lack of concern for this project i thought I'd still point something out (i've known about it for a long time now but just decided to mention it) according to the man pages, the first parameter of select() is the max socket number being polled, plus 1. you have implemented MAXCONNECTIONS as the first parameter. There is no guarantee that the value returned by socket() or accept() will be lower than MAXCONNECTIONS, therefore it is possible to end up with connections being opened that are not pollable. Furthermore, to extended this report to a suggestion as well, a poll() system would be nice (I'm pretty suprised you haven't made one already considering the work you've put into the other various 'features') and for good measure i'll repeat my request to make a ./Config option which will allow the user to compile a group of .o's instead of .so's which then get linked (this would cut down on compile time dramatically)... and fixing those <0 count bugs would be cool too - fez | ||||
| 3rd party modules | |||||
|
|
It's indeed not entirely correct, but in practice it works.. we use MAXCLIENTS (which is MAXCONNECTIONS-4) and LastSlot >= (MAXCONNECTIONS-1) checks everywhere. Anyway, poll() (+ epoll, kqueue and all those other fun things) and a total I/O engine rewrite (which will make the code much more readable / clean) is scheduled for 3.3*. Your seperate modules requests is still in 0001631, no need to re-report. And no, adding yet another bogus entry with 'HI PLZ TO DELETE' and 'You don't care to fix bugs anyway' won't gain you much except that it will make you look very childish again... Unfortunately you were totally wrong with your +q-without+o stuff, this is by design (+q is no 'level' if it's not in PREFIX=) and would cause mass confusion if implemented like you would (since you see people kicking/settings modes without prefix), you know... sometimes ircd coders do think... And perhaps they think/know a bit more about all the consequences of things than you do? Just a very weird idea.... |
