Re: 2.0.6 released

On Wed, 23 Mar 2005, John Ogness wrote:

>
> Of course, if you have a bunch of registered processes in the same group 
> (which you probably do), than any of the other processes could respond 
> directly to Process B's event and everything continues ok. But this generates 
> twice as many context switches.
>

Right, but even if you have a group of registered processes, you have to 
make sure there is no hard limit on their number else the deadlock you 
described above could still happen if *all* your processes are busy 
servicing Dazuko requests that fit into that pattern of: Process A makes 
Process B do stuff that generates more Dazuko requests (for group A)... :/

It took me a while to realize this.  Actually this is why I had deadlocks 
before.... But yeah I am glad we are discussing this here as hopefully 
someone else might run into this same issue (that is, until 2.1.0 is 
adopted!).  :)


>
>
> Yes, this is correct. This problem stood on the Dazuko TODO list for nearly 
> two years. But in 2.1.0 it is finally being handled.
>

Haha well congratulations on getting around to fixing it! :)

>
>> Hmm that's good to know.  In my app I probably won't be using more than one 
>> group and I am assuming the system has no other apps using dazuko.. but.. 
>> is there any way to lock dazuko in 2.0.6 (I could just grok the sources to 
>> find out)?
>
> Lock Dazuko? So no one else can register? No, this is not possible. Should 
> this be a feature for the TODO list? Using Dazuko with RSBAC allows something

It's up to you to put it in the todo list.  I am not sure how useful it 
is, really.  The only reason I asked is because it could be a temporary 
workaround to avoid the overwriting of the access mask until 2.1.0 comes 
around, but, I see 2.1.0 is just about finished anyway.. so the point is 
moot.

In general artificially imposing limites on kernel subsystems doesn't 
seem to me to be that useful unless it is to avoid a class of bugs... but 
that's just my two cents..


>
>> If not don't worry about it (not that I imply you should) as I look forward 
>> to usiung 2.1.0 as soon as I get around to seeing how stable it is.. (still 
>> playing around with my actual app before I can work on such optimization 
>> steps).
>
> 2.1.0-pre3, which should be posted any day now (as soon as I actually find 
> some free time), runs very stable. It is much faster, has many new features, 
> produces more reliable events for Linux 2.2/2.4 and FreeBSD 4/5, and fixes a 
> lot of longstanding known problems with previous versions.
>

Sounds sweet.. Thanks very much for the good work and the very useful 
software!

-Calin