locking & iovecs

[Waldemar Kornewald]

Brooks Davis wrote:
>>Oh, now that we talk about alternatives: did you consider using iovecs 
>>instead of mbufs? Be Inc. said that BONE, the new netstack of BeOS (now 
>>Zeta), can handle huge amounts of data much better than mbufs because 
>>iovecs reduce the number of copies made when fragmenting...though, there 
>>has never been a real comparison.
> 
> Rewriting the network stack to use an alternate method of storing
> network data is a hugh undertaking.  It's not an idea that's likely to
> get any sort of traction in the project unless someone presented running
> code and a massive performance improvement across the entire spectrum of
> applications.  Unless you mean splitting buffers up into TCP packets,
> fragmentations is a network configuration bug in 99% of all cases. :)

Sorry, that is no bug. :)
Maybe we will try it after we get our code/port stable. As we will not 
port all of your protocols it should be less of a problem to change our 
stack. I can post the results here (in some years ;).

>>>You can implement mutexes using semaphores, but semaphores tend to be a
>>>more expensive since they are more expressive them mutexes.
>>
>>Using a benaphore instead would improve speed significantly and as you 
>>only use macros we can easily replace those with our benaphore code, is 
>>that really so simple? Sorry, I cannot believe that. :)
> 
> Once GIANT is really gone, it may be nearly that easy.  We're a ways
> from that though.

So, the code is not fully thread-safe yet (we want to drop GIANT)? Then, 
I misunderstood something. Will 5.3 be freed of GIANT?

Bye,
Waldemar Kornewald