lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] [patch #9283] Returning access modes with fcntl


From: Joan Lledó
Subject: Re: [lwip-devel] [patch #9283] Returning access modes with fcntl
Date: Fri, 24 Mar 2017 16:17:47 +0100

The current stack has a big global lock too, so I think we're not
losing performance. In fact, AFAIK the Hurd doesn't have
multiprocessor support, it works with only one logical processor. And,
since LwIP is designed to be lightweight, it'll probably perform
better.

2017-03-23 21:55 GMT+01:00 address@hidden <address@hidden>:
> Continuing on the list, since this is somewhat off-topic to the patch...
>
> Joan Lledó wrote:
>>
>> Regarding your question, the current stack 'pfinet' is running in a single
>> task, but of course it is multithreaded. There's one thread that listens
>> to
>> incoming requests from user tasks and creates a new thread for attending
>> each
>> request.
>>
>> The LwIP port works exactly the same way, each request gets a new thread
>> that
>> calls the proper sockets API function. I think that's enough since the
>> sockets
>> API is safe-thread, but I'd appreciate your comments.
>
>
> Well, from the stability point of view, that should be enough, yes.
>
> My thoughts were about the performance rather: even in core locking mode
> (default since v2), lwIP has a, say, "big network lock". To get decent
> multiprocessing performance, we would need someone to identify smaller
> locking areas. Many of them are probably multi reader single writer locks.
> However, noone has volunteered to do this, yet. Mainly because lwIP is not
> really used in multiprocessor systems, I guessed (or if it is, running it on
> one core is enough since networking is often not the only thing a machine
> needs to do).
>
> Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]