FreeLists / openbeosnetteam / [openbeosnetteam] Re: End of select on R5

[philippe.houdoin@xxxxxxx]

> So, Net+ calls select with an nbits value of 25, which should mean
> it's waiting on about 21 sockets! 

Not necessarly, it could be simply waiting on one single socket, 
but with a fd value of 24.
Anyway...

> In fact I'd go so far as 
> to say that there seems to be a memory leak somewhere in R5's 
> select as when you run the select-test_big with large collections 
> of sockets the normal result is a KDL shortly after, often with 
> malloc being the culprit. 

BTW, Brian Swetland said same thing once, on #newos.

> While this could be our code, I'm not convinced we have
> that sort of problem, though it could be us :)

How could!? Our net_kit code is bug-free, isn't it!?
;-)

BTW, what's the purpose to store monitoring socket events in struct socket 
sel_ev field TOO?
I mean, if in checkevent() we callback the driver on_socket_event() function 
for an event which is NOT monitored, on_socket_event() won't do anything: 
nsc->selectinfo[event].sync == NULL in this case...

Did these dual events bitmasks is really needed?
Did I miss something?

Oh, you're right in your checkevent() comment about the need to lock 
socket struct for thread-safetyness.
Not only in checkevent() (which I should have named socheckevent(), 
I guess...), alas.

> I guess this should really bring to an end our hopes of using the
> kernel's select on R5.

I'm starting to think that way too.
Bad luck for all people waiting for (doing) an 
BeOS_network_stack_replacement, "a la" MDR...
:-(

> Bring on the new kernel - we're ready!

Always! :-)

-Philippe, without a huge lack of sleeping time today