[openbeosnetteam] Re: Mailing lists and network team questions

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: