Re: [xml] Query Regarding Revision 2121 in SVN for entity nesting check in parserinternal.c

[Daniel Veillard <veillard redhat com>]

On Wed, Feb 20, 2008 at 05:38:30PM +0200, Andrew W. Nosenko wrote:
> On Feb 20, 2008 5:08 PM, Daniel Veillard <veillard redhat com> wrote:
> > On Wed, Feb 20, 2008 at 03:04:42PM +0200, Andrew W. Nosenko wrote:
> > > On Feb 20, 2008 2:50 PM, Daniel Veillard <veillard redhat com> 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.

  no problem.

> >   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)

  that trick is a bit ugly, but 1/ works 2/ is very portable
and it's needed to check a very borderline problem, so I'm not
aiming at the easiest to understand frankly, still I tried to
explain in the comment.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/