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


Groups > comp.lang.c > #66495

Re: setjmp, longjmp, parser state, threads

From "Morten W. Petersen" <morphex@gmail.com>
Newsgroups comp.lang.c
Subject Re: setjmp, longjmp, parser state, threads
Date 2015-07-28 16:39 +0200
Organization Aioe.org NNTP Server
Message-ID <mp846f$282$1@speranza.aioe.org> (permalink)
References <mp5uhv$b7c$1@speranza.aioe.org> <876155yymh.fsf@bsb.me.uk> <mp7fco$el5$1@speranza.aioe.org> <mp83ho$cm$1@dont-email.me>

Show all headers | View raw


On 28.07.2015 16:29, James Kuyper wrote:
> On 07/28/2015 04:44 AM, Morten W. Petersen wrote:
>> 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.
>
> That's a start in the right direction. But you should also understand
> that threads can be a very efficient and effective way of radically
> increasing the amount of time it takes to complete a task. Creating a
> new thread which either has too little work of it's own to do, or which
> must spend too large a fraction of it's time coordinating its work with
> other threads, can really ruin the performance of a program.

Yeah..  well, I've been thinking about threads and all that jazz, and
to me it looks like compiling the same code, with/without #defines &
threads and then making a runtime abstraction for which function to
call (based on file size for example) could be the right way to go.

For very small files, firing up a thread seems like it could take
longer than it would take to parse the entire file without 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