[openbeosnetteam] Re: Mailing lists and network team questions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 16 Mar 2006 14:59:20 +0100 CET
Waldemar Kornewald <wkornew@xxxxxxx> wrote:
> Axel Dörfler wrote:
> > just a minor observation: since our current networking stack is
> > already
> > integrated, and at least somewhat working - would it be more or
> > less
> > work to get it work correctly than porting a whole new stack (even
> > if
> > that stack would then be better)?
> The netstack is absolutely not dead-lock free. It would take
> incredibly
> much time to get it working reliable. We might try to create a BGL
> around it, but seriously...we need something better. Also, some
> features
> in our netstack don't work (non-blocking socket?).
Well, that's not a long list. And this is a port after all - why do you
think the next one would be less work than fixing those bugs?
I mean I don't like what I see whenever I look into our networking
stack code - but that doesn't mean it's really that bad code - just
badly written :)
> > Just wondering if it's worth the effort. Also, if we don't intend
> > to
> > stick with the FreeBSD stack for R2, it makes the porting effort
> > less
> > valuable - plus, if that's the case, it would also doesn't make
> > much
> > sense to create BSD like APIs in the kernel, instead, it would be
> > better to adapt the stack to our kernel.
> I think that LWKT is a very valuable API, in general. We should use
> it
> in VFS, drivers, and everywhere possible. Maybe even export it to
> userland, so we can finally get rid of all those dead-locks in
> app_server, etc.
> We need better, more productive, and safer APIs. We should use smart
> pointers and dead-lock free synchronization where possible.
> Unfortunately, we're not making use of tools that help writing better
> code.
>
> That's why I think DragonFly is better.
It's not, and lwkts are not - they just have a different objective
(besides the fact, that right now, DragonFly is certainly better than
Haiku, alone for the fact that it works :-)).
As I tried to explain, as long as there is no way to unconditionally
interrupt a non-interrupt thread by another one, this technique is not
interesting for a Desktop oriented (responsive) operating system.
Bye,
Axel.
Other related posts:
