Re: [bme-develop] emoticon code in cvs

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

> Hi,
> 
> > > 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.
> >
> My thought about the multi threading issues is as follows: if you 
> have a 
> pointer to an object it is possible that a method of an object say 
> Items() 
> is called twice a the same moment resulting in a crash....(at least 
> that's 
> why you have to synchronize methods in java....to prevent the method 
> from 
> being called twice a the same moment)....If BeOS does handle this 
> calling 
> fine, we are allright...because the BList and the Emoticon objects in 
> it are 
> online loaded once! then they aren't changed anymore....

Yes, I wouldn't call methods from different threads. However instead of 
passing a pointer to the List itself, pass a pointer to the actual data 
(can be obtained from BList::Items()) along with the number of items. 
Then each thread will have their own independent pointer to the data, 
and providing the actual list data is not changed, they can both read 
the actual items in the list at the same time.

Otherwise you can use a semaphore to make sure only one thread accesses 
the BList at any time (see the kernel kit documentation in the BeBook). 
However, the first solution is better IMHO, as we know that the data 
won't change after it's loaded.

> btw Simon you're right about the IconManager/IconHandler stuff....I 
> did this 
> for this reason: the list loaded by IconLoader should be passed to 
> the 
> IconManager, which will be passed to the IconHandler....but I can 
> also make 
> it more safe(in deleting) to pass the List to the Handler and 
> construct the 
> IconManager  in the handler, I will change it!

I would have the IconHandler deal with everything. So in the main bme 
code we just need
iconHandler = new IconHandler();
and then the icon handler constructor takes care of creating the other 
classes it needs, creating a list of emoticons, populating it, managing 
the list, etc.

> regards,
> Tim

Simon