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

["David Reid" <dreid@xxxxxxxxxxxx>]

> > 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.

Well, try running the select_test_big with values above 10 and see what you
think :(

> > 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?

Well, review the code and tell me. I think you'll find the dual check is
required due to the way that checkevent works...

>
> 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...
> :-(

That was never high on my list of priorities anyway (though I know some of
you wished for it).


david