Re: [bme-develop] emoticon code in cvs

[Simon T. <sim...@ga...>]

> Hello
> 
> > > I'm 
> > > expecting major program crashes because of simultanious accessing 
> > > the
> > > BList(via a pointer passed in the message) and the Emoticon
> > > structure....I
> > > think simultanious methods calls will cause that...so we have to 
> > > test
> > > for
> > > that....I have a solution for the Emoticon Structure....archiving 
> > > it
> > > into
> > > the message(yeah I know that would increase the memory 
> > > usage...but 
> > > if
> > > it
> > > isn't possible in another way...)....the BList of emoticons will 
> > > be 
> > > a
> > > problem though...since a BList can't be archived...:S any 
> > > suggestions?
> >  
> > Hmm the BList shouldn't chage after it's been loaded right? I can't 
> > see 
> > why there would be a problem with 2 threads accessing the list at 
> > the 
> > same time (as long as they use different pointers, owned by the 
> > threads 
> > themselves). Saying that, I don't think you should call BList 
> > methods 
> > from other threads, but providing the BList doesn;t change, you 
> > should 
> > be able to pass the pointer returned by BList::Items() along with 
> > the 
> > number of items returned by BList::CountItems().
> > 
> > I'm know very little about multithreaded issues though, so I may be 
> > wrong.
> > 
> I agree with Simon, there should be no problem sending pointers to 
> Emoticons or to the BList. Actually that is how the MsnBuddy and 
> MsnList work. Everywhere I need a MsnBuddy object for something I 
> request it to the MsnList through the Common::getMsnBuddy(cont char*
> ,BHandler) method and it returns a pointer to the MsnBuddy object. 
> You 
> would only see problems if a particular object holds some kind of 
> internal state, where multiple/simultaneous calls would cause the 
> internal state to misbehave. I am not sure if the BLists hold any 
> internal state, but that would be something you would find in the 
> BeBook, so I am guessing BLists are multithreading safe, the problem 
> would be the BString objects, where the BeBook warns about it not 
> being 
> multithreading safe. I think it would be ok as long as you don't 
> modify 
> the contents of the BString from different threads. Maybe limit the 
> Emoticons public access to the BStrings.

I'm not sure BLists are thread-safe for write operations (maybe that's 
why the user with the fast connection experienced a crash on logging 
in?). Passing a pointer to the actual list of items along with the the 
number of items should be fine for reading though.

> Regards,
> Daniel

Simon