Archived

This forum has been archived. Please start a new discussion on GitHub.

Precisely how are Ice threads implemented?

I need to use threads on (what I'm told is) a Red Hat Linux 3 system. My past experience is with Sun threads on Solaris, so I am using the "closest thing to that," namely pthreads. These however seem to make my program coredump at random times; I can never predict whether it will run to completion, coredump at Point A, coredump at Point B, coredump somewhere else, etc.

The only other person I know who uses any form of threads on this platform is my colleague Mark Wilson who has also been a (frequent?) poster here -- and HE says that HE uses "Ice's thread support" when HE needs threads.

The only OTHER people I know who seem to have "used threads" on this platform, is YOU guys -- the authors of Ice. So I want to ask you, how'd you do it? How do YOU get "stable" behavior out of "threads" on Red Hat Linux 3? Do you use pthreads under the hood, just perhaps according to some subtle usage paradigm that I haven't yet encountered? Or do you implement your own, custom, "thread-like" abstraction, from scratch, entirely in user/application space/code? I ask because I seem to need to reinvent this particular wheel. *SIGH*

Thanks,

Chris

Comments

  • Ice uses pthreads on non-Windows systems. Check out the IceUtil source in the Ice source distribution for how it is implemented.

    If you are interested in simplifying life, you should consider using the Ice threads library yourself. It beats the heck out of writing directly to the pthreads API.

    Cheers
  • I should have also mentioned that Ice's C++ threading and signal handling abstractions are well-documented in "Chapter 29. Threads and Concurrency with C++" of the Ice documentation.

    Cheers
  • bernard
    bernard Jupiter, FL
    Another C++ thread abstraction library you should consider is boost-threads:
    http://www.boost.org/doc/html/threads.html

    Cheers,
    Bernard
  • Thanks...

    Thanks, Brent...

    I will attempt to follow your recommendations; whether that shall actually prove POSSIBLE, however, remains to be seen, for reasons I won't bemoan here/now.

    Further bulletins as events warrant,

    Chris
  • Findings

    Brent,

    I've just now found the IceUtil source code and will look at it... but before even looking for that, my pursuit of other avenues-of-inquiry seems to have paid off: I've found what appears to be the real culprit in my Red Hat 3 pthreads problems.

    To wit: I'm compiling with g++ (v3.2.3, I think; I find it hard to be certain). The g++ manpage (which constitutes all the doc I have, and which actively disagrees with g++'s own "--help" output on a few points) says that "when using threads," I should include the -pthreads and -fstack-check flags on the compile command. I have been doing this.

    It turns out, after much trial-and-error, that using -fstack-check gives me binaries which randomly coredump; omitting it gives binaries which do not, i.e. which are "stable."

    This seems to solve my immediate problem, although now it raises the question of "what is -fstack-check supposed to do, and what is it actually doing?" Is it behaving correctly or incorrectly? It's not necessarily as simple as "coredump = incorrect:" if -fstack-check generates stack-checking code, and that code's normal behavior is to coredump the process if stack constraints are violated... then the "random coredumps" could simply be the stack-checking code doing its job! Anybody reading this, know for sure?

    Chris
  • ChrisC wrote:
    This seems to solve my immediate problem, although now it raises the question of "what is -fstack-check supposed to do, and what is it actually doing?" Is it behaving correctly or incorrectly? It's not necessarily as simple as "coredump = incorrect:" if -fstack-check generates stack-checking code, and that code's normal behavior is to coredump the process if stack constraints are violated... then the "random coredumps" could simply be the stack-checking code doing its job! Anybody reading this, know for sure?

    I'm afraid we don't know the answer to this question. We have never used -fstack-check for our code. I recommend to post this question in a Gnu C++ newsgroup.
  • bernard
    bernard Jupiter, FL
    Hi Chris,

    You can find the g++ version you're using with g++ --version.

    And the documentation for various GCC releases is available online at: http://gcc.gnu.org/onlinedocs/

    Cheers,
    Bernard
  • G++ etc.

    Thanks, Brent and Bernard!

    I will indeed take the GCC-specific questions to a GCC newsgroup; my only real intent in coming here, was to speak to the one "person" I know (of)," who had written pthreads code that allegedly ran on Red Hat 3 without random coredumps, to found out how they did it. Period. Beyond that, I fully agree, this is the wrong place for GCC / G++ questions. I merely mentioned the "next level of question" so as to indicate where I would be going from here. I should have added that "I will now go to the GCC newsgroups" or something...

    Bernard, thanks for the info on the --version switch to G++, and the pointer to the online docs. Whew, that's a lot of material! Thankfully it is well-enough organized that I was able to quickly find the section on -fstack-check -- it just doesn't really tell me a whole heckuva lot. Again, a point for more-detailed discussion in the newsgroups.

    Brent, I've also just now pulled my Ice manual out of mothballs, with the intent of re-reading chapters 2, 6, and 8 (and then, perhaps, others). So far, I've gotten through Chapter 2 with a relatively small number of questions -- but I just started Chapter 6 and they're already starting to pile up. I just don't seem to have ever been exposed to a lot of the concepts, facilities, paradigms, etc. etc. that you guys either mention, use in passing without calling particular atention to, or simply seem to assume knowledge of, in the text of the manual... So, you (or someone) will undoubtedly be hearing from me with lots of dumb-newbie questions, at great length in the near future...

    Again, thanks to both of you, and "further bulletins as events warrant." Oh, and this can be the end of this particular thread as far as I am concerned; I have no further Ice-thread-specific questions at this time. :-)

    Chris