[openbeosnetteam] Re: panic when creating socket of unknown type
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 16 Apr 2009 22:48:16 +0200 CEST
Romain <romain.haiku@xxxxxxxxxxx> wrote:
> >Sorry, I intended to answer that one, it just got buried under
> >a lot of other mails.
> No problem, i just feared it got lost because there was quite a lot
> of
> posts this week.
Not lost, but sometimes I need so much time to answer, it has pretty
much the same outcome... so any reminder is welcome!
> >This particular issue is fixed in r30188, thanks for your
> >investigation!
> nice. There is another issue i saw in create_socket in case of error:
> The
> mutex is destroyed before calling the socket destructor, but this
> socket is
> also destroyed in the destructor. This should be removed from
> create_socket.
Did so now, thanks! I've completely overseen that one.
> >This would not be the correct solution, as a socket can be in other
> >lists as well exclusively (ie. in its parent socket "pending" and
> >"connected" lists).
> ok. pending_children sockets are the ones waiting for an accept call,
> and
> connected_children sockets the ones that were accepted ?
Not quite: pending_children contain those sockets that were spawned
from a listening socket, but are not ready yet to be accepted.
connected_children contains the sockets ready for being accepted; in
case of TCP sockets, they need to become established to get into the
that list.
Once the socket has been accepted, it's removed from its parent, and
gets its own file descriptor. It also becomes part of the global
sSocketList, then.
> >> - Is it ok to load the net_socket module as soon as the stack is
> >> created
> >> (It seems this was supposed to be done automatically only when
> >> needed) ?
> >I will look into this problem now. You can't just load the module,
> > as
> >you would then no longer be able to unload the stack.
> ok. I will watch the commits to see how it will be fixed :)
Done, although it's now pretty much as you proposed -- the stack
loading works different since some time, though, so this does not
prevent the stack from being unloaded; I remembered that incorrectly.
Bye,
Axel.
Other related posts: