ServiceOwnerChanged wakes up everybody?

[Kimmo.Hamalainen at nokia.com]

> -----Original Message-----
> From: ext Havoc Pennington [mailto:hp at redhat.com]
> Sent: 09 June, 2005 16:05
> To: Hamalainen Kimmo (Nokia-M/Helsinki)
> Cc: andersca at imendio.com; dbus at lists.freedesktop.org
> Subject: RE: ServiceOwnerChanged wakes up everybody?
> 
> 
> On Thu, 2005-06-09 at 15:13 +0300, Kimmo.Hamalainen at nokia.com wrote:
> >  [I wondered, among other things, whether the
> > wait-forever-for-more-memory strategy used in some parts of 
> the code fits
> > well to embedded devices that may have e.g. ulimit to the 
> process. It could
> > cause a deadlock...]
> 
> Waiting is only used where there's nothing else possible I could think
> of (well, maybe exiting would be the alternative). In most places OOM
> causes an error. Exiting the system dbus is going to break your system
> basically so exiting isn't a good option imo.

The only way to do it right would probably be allocating the memory
statically or dynamically already in startup of the daemon. That could mean
managing statical buffers in the code and waiting for free buffers, though, if
multiple threads are used.
 
> > After reading some of the D-BUS code I noticed several 
> places where alloca()
> > could be maybe used instead of strdup() and free(). That 
> would probably require
> > maximum sizes for e.g. service names etc. but could speedup 
> somewhat.
> 
> The current performance profile doesn't have memory 
> allocation as a hot
> spot iirc. The major problem right now is the message parsing code.

alloca() is also useful in avoiding memory leaks and fragmentation. There
is probably lots of unused space in the stack anyway, because the recursion
levels are not very deep (as in e.g. compilers?).

BR; Kimmo

> 
> Havoc
> 
> 
>