[haiku-commits] Re: haiku: hrev45507 - src/add-ons/kernel/network/notifications
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 22 Apr 2013 12:08:29 +0200 (CEST)
On April 22, 2013 at 11:49 AM Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> As written in my last mail, the race condition for the network
> notification module still exists, though. At least adding a TODO would
> be nice. Maybe Axel can shed light on how the module is supposed to be
> used, since finding a solution would be nicer.
Sorry, I forgot to answer that one: basically, the notification module is being
loaded as long as the network stack is loaded. It's a separate module so that
applications listening to network changes will not be disconnected from the
stack in case it is reloaded; as long as there are any listeners, the
notification module will stay in memory.
I've already talked with Rene that the best solution would probably be to keep
the notification service registered only when the stack is loaded. New
applications could then no longer register a listener while the stack is being
reloaded, but it's the same now in case there weren't any listeners in the first
place.
Also, an application could then not change or remove its listeners while the
service is not registered, which isn't really ideal, but probably not that bad
either.
Alternatively, one could enhance the generic syscall mechanism to be able to
load the module providing the API on the fly, so that that one could then take
care of registering the service in case the network stack is not loaded. This
would allow to completely decouple the needs of userland applications, and the
network stack.
Bye,
Axel.
Other related posts:
