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

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


Red Hat Virtualization group
Daniel Veillard      | virtualization library
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]