On Feb 20, 2008 5:08 PM, Daniel Veillard <[EMAIL PROTECTED]> wrote: > On Wed, Feb 20, 2008 at 03:04:42PM +0200, Andrew W. Nosenko wrote: > > On Feb 20, 2008 2:50 PM, Daniel Veillard <[EMAIL PROTECTED]> wrote: > > > > However I assume in case of scenarios where there is a parser > > > > context > > > > per thread, thread-safety is required, right? > > > > > > No. try to understand how the added check works. > > > The point is make sure that for a given parsing context you always get > > > different ids when you create new input streams. That code does it, > > > and the comment is right. > > > > Sorry, but (IMO) there indded may be a problem if defferent concurent > > threads running on the different CPUs. > > The only thing we need is that when different input are created for > *the same* parser context they get different ids (understanding the > parser test will help you verify this assertion). Only one thread can > use a given parser context at a time (that's a requirement of libxml2 > thread usage http://xmlsoft.org/threads.html). I state this code fullfils > the requirement, but please show me the sequence of event leading to your > problem. At worse 2 threads take the same initial value, get the same > id but since they have to operate on different parser contexts this > is absolutely not a problem.
If one and the same 'id' for different parser contexts is not a problem, then problem doesn't exist at all, as for me. Thanks for explanation. > So tell me how do you get your problem ? > > Note, the probability of other threads allocating 4 billions inputs > in the meantime is IMHO neglectible and would not be solved by a > critical section. I thinked not about mutexses but about some sort of atomic operations (like g_atomix_int_*() from Glib) for 'id', but after your explanation see that it is unneeded. And, of course, it would not help with overlap through int limit anyway (which condition, IMO, is very unrealistic and I don't worry about it ever) Again, thanks for explanation. -- Andrew W. Nosenko <[EMAIL PROTECTED]> _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
