[interfacekit] Re: Anyone working on BMessageQueue

>Yes, go with the straight implementation.  If there is some change 
that 
>seems extremely cool/necessary just bring it up with the group.  
>Improving on failure modes is certainly something you could do without 
a 
>second thought.  For example, several of the archiving functions have 
>segment violations if you pass NULL parameters, which simply doesn't 
fit 
>into my notion of a well-behaved API, and you can be sure that my 
>implementation does no such thing. ;)

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 
unblocked because the BMessageQueue has been deleted, they properly 
return without doing anything potentially dangerous.

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.

>We have a BInvoker implementation that I will check in soon, courtesy 
>the BlueOS guys.  Please hold off on checking in until I say "OK" -- 
>there's still a bit of administrivia I want to get sorted out first.  
>Shouldn't take more than this week to iron out.

I will look at BMessageFilter next then instead of BInvoker.  
Unfortunately, I got your message about 1.5 days too late.  I have 
checked stuff in I am afraid.  I have stopped now and I will take 
responsibility for cleaning up anything which you don't like.  I did 
try to use the hierarchy you mentioned in another message.  Sorry for 
this and I hope it isn't a big deal.  Let me know what you would like 
me to do and I will clean it up.

>Yes, the docs looked pretty good to me as well.  In particular, I 
>enjoyed your lengthy in-source discussion in AquireLock().  One thing 
I 
>want to ask is that you use CppUnit for your testing framework; it 
will 
>help us easily integrate all our tests into one all-encompassing suite 
>-- which, given the total amount of work we're doing, is definitely a 
>must-have.

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.

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

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

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

--
Jeremy Rand
jrand@xxxxxxxx

Other related posts: