[interfacekit] Re: Anyone working on BMessageQueue

>I have also done the same.  With BMessageQueue, I found that if a 
>thread blocks trying to do an AddMessage(), RemoveMessage() or 
>NextMessage() while another thread holds the lock and does a delete, 
>memory will be corrupted.  I usually get segment violations but not 
>always but definitely memory was being corrupted.  My implementation 
>doesn't do that.  If the Add, Remove or Next is blocked and becomes 

[snip]

>I doubt this is a big deal to Be engineers though since the main user 
>of BMessageQueue is generally B classes themselves, like BLooper.  If 
>BLooper never does this, then it isn't a big deal.

True, but then there is the implicit assumption in BMessageQueue that 
its clients magically know what *not* to do.  You did the right thing; 
classes in the API should be robust in a self-contained way.

>>Yes, the docs looked pretty good to me as well.  In particular, I 
>>enjoyed your lengthy in-source discussion in AquireLock().  One thing 
I 
>
>Thanks.  I thought it was most important to have those details in the 
>source itself than in a seperate document.  BLocker seems simple but 
>there are a couple of gotchas and I don't want someone tricked up in 
>the future.

Agreed.  In fact, I'd like to see *all* of our documentation contained 
in the relevant source files, and generate our HTML straight from the 
source.  The idea being that devs are more likely to maintain 
documentation that is right in front of them then if they have to go 
elsewhere. =)  Ithamar and I will hopefully iron out exactly how to do 
this over the next couple of days (tonight, if we're lucky).  Using an 
existing tool, like Doc++ or doxygen, is obviously attractive, but you 
basically get docs formatted "their way" and there doesn't seem to be an 
easy way to add extensions.  However, taking the time at this juncture 
to *create* a tool which does what we want isn't really feasible.  We'll 
figure something out, I'm sure.

>I haven't heard of CppUnit, but I will familiarize myself and ensure 
>that my current tests are moved to that framework.

Based on a quick glance, I think you could probably wrap what you've 
already done in CppUnit pretty easily.  Once you get used to it 
(CppUnit, that is), it's pretty dang easy to use.  I'm going to check it 
into the repository as well; undecided whether to put it in the top 
level tools dir, or in an app_kit tools dir.  Any thoughts, guys?

>Thanks for the comments and again sorry for any problems about CVS.

Sure and don't sweat it.  You put everything where it should be, so 
don't worry about backing files out.  Mainly, I don't want to have folks 
commiting all manner of code until I have the process finalized and the 
scheduling/progress stuff in place.  Just means I need to get on the 
ball. ;)

e

Data is not information, and information is not knowledge: knowledge is 
not understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: