Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #66481

Re: setjmp, longjmp, parser state, threads

Show all headers | View raw

On 28.07.2015 01:22, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
> <snip>
>> I'm writing an XML parser, which will also be built to support
>> threads.
>
> That's a good idea.  Pretty much all utility code should aim to be
> thread safe or thread aware.  (I'm not being sarky -- I know that may
> not be what you mean by "support" but it will be a valuable consequence
> of any consideration of threads.)
>
>> Now, I've been looking at bit at threads, parser state, setjmp and
>> longjmp.
>>
>> Threads will be an important optional feature to minimize the amount of
>> time it takes to parse an XML file.
>
> This is not an obvious fact that you can just assert.  You may have some
> evidence for it, but if not I think you should try it out first as I
> suggest below

Well I've gathered that threads aren't necessarily the one right way to
reduce the time it takes to complete a task.

> <snip>
>> Am I right in thinking that since the program will use threads at some
>> point, it is a good idea to have a parser object instead of a setjmp /
>> longjmp thing?
>
> You should have a parse object to reflect the state of the parse (error
> flags included) because that's the right thing to do anyway.  And you
> should generally avoid setjmp and longjmp unless they are forced on you
> (i.e. they appear to be the only way out of some serious design
> problem).  Support for threading does make the arguments for a parse
> object and against setjmp/longjmp a bit stronger, but it's not the
> reason to make that choice.
>
> As for using threads for parsing XML, I suggest you try an experiment.
> Write a throw-away threaded program the builds a tree structure from
> some text input (you can invent your own to be favourable to threaded
> parsing) and see if you can indeed make it as fasted than a non-threaded
> version.  You've decided that threads will make parsing faster, but I
> find that hard to believe though I'd love to see that preconception
> overturned.

I was thinking of handing off certain parts of the parsing to
specialized functions, so that for example the starting element tag in
XML with all its attributes can be handled by a separate thread and
then the main thread can proceed to the element content.

Another is having a thread read from the stream and build an internal
representation of the incoming XML data and have another thread work
on that representation.

But it looks like the smartest thing to do is to make everything fast
without threading first, and maybe analyze distinct parts of the
parsing, having a file completely read into memory before "the real
work starts" for example.

> Such an experimental program would teach you a lot about writing
> threaded code (I think you are new to that from what you've written) and
> it would force you to think about how parsing can be broken up into
> suitable work units (which it one of the barriers I have to thinking
> that there is any value in using threads).  Both of those would be
> valuable to you even if the code is eventually thrown away.

Yes, maybe I'll do that.  It might be a little bit too theoretical
though and more gratifying to start using threads in the parser instead.

> But the big point is that either you'll learn that threads are not a
> good match to this problem (and that's a big win for you if it's true),
> or I'll learn that I've got an unhelpful mental picture model of what
> threads can do (that's less of a win for you, but you'll have done me a
> service).  Surely all of that is worth a short experiment?

Short snippets of code are good for a theoretical understanding of
something, but I think I understand threads well enough.  There is
a small memory cost, some cost of context switching and managing
threads, and working with large data sets can for example be slow
because it is outside of the CPU cache.

Is there anything else to consider using threads?

-Morten

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

setjmp, longjmp, parser state, threads "Morten W. Petersen" <morphex@gmail.com> - 2015-07-27 20:50 +0200
  Re: setjmp, longjmp, parser state, threads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-28 00:22 +0100
    Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state, threads] Jeff Higgins <jeff@invalid.invalid> - 2015-07-27 21:00 -0400
      Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state,   threads] Ian Collins <ian-news@hotmail.com> - 2015-07-28 13:57 +1200
        Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state,   threads] Jeff Higgins <jeff@invalid.invalid> - 2015-07-27 22:13 -0400
          Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state,     threads] Ian Collins <ian-news@hotmail.com> - 2015-07-28 17:12 +1200
            Re: OT - XML Parallel Parsing Jeff Higgins <jeff@invalid.invalid> - 2015-07-28 09:46 -0400
          Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state, threads] "Morten W. Petersen" <morphex@gmail.com> - 2015-07-28 10:07 +0200
            Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state, threads] raltbos@xs4all.nl (Richard Bos) - 2015-07-28 09:28 +0000
              Patents, was [Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state, threads]] "Morten W. Petersen" <morphex@gmail.com> - 2015-07-28 11:41 +0200
                Re: Patents, was [Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state, threads]] Stephen Sprunk <stephen@sprunk.org> - 2015-07-28 20:53 -0500
                Re: Patents, was [Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state, threads]] "Morten W. Petersen" <morphex@gmail.com> - 2015-07-29 05:15 +0200
                Re: Patents, was [Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state, threads]] Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-07-28 22:34 -0600
      Re: OT - XML Parallel Parsing, was [Re: setjmp, longjmp, parser state, threads] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-28 03:06 +0100
    Re: setjmp, longjmp, parser state, threads "Morten W. Petersen" <morphex@gmail.com> - 2015-07-28 10:44 +0200
      Re: setjmp, longjmp, parser state, threads Ian Collins <ian-news@hotmail.com> - 2015-07-28 22:14 +1200
        Re: setjmp, longjmp, parser state, threads "Morten W. Petersen" <morphex@gmail.com> - 2015-07-28 15:17 +0200
      Re: setjmp, longjmp, parser state, threads Jeff Higgins <jeff@invalid.invalid> - 2015-07-28 08:35 -0400
      Re: setjmp, longjmp, parser state, threads James Kuyper <jameskuyper@verizon.net> - 2015-07-28 10:29 -0400
        Re: setjmp, longjmp, parser state, threads "Morten W. Petersen" <morphex@gmail.com> - 2015-07-28 16:39 +0200
  Re: setjmp, longjmp, parser state, threads jadill33@gmail.com - 2015-07-28 06:47 -0700
    Re: setjmp, longjmp, parser state, threads "Morten W. Petersen" <morphex@gmail.com> - 2015-07-28 16:56 +0200
      Re: setjmp, longjmp, parser state, threads Noob <root@127.0.0.1> - 2015-07-28 18:04 +0200
      Re: setjmp, longjmp, parser state, threads jadill33@gmail.com - 2015-07-28 10:53 -0700
        Re: setjmp, longjmp, parser state, threads "Morten W. Petersen" <morphex@gmail.com> - 2015-07-29 04:59 +0200
  Re: setjmp, longjmp, parser state, threads Bartc <bc@freeuk.com> - 2015-07-28 16:29 +0100

csiph-web