Professional Web Applications Themes

Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X) - Mac Programming

I'm cruising along trying to write a program that uses threads. Not the simplest task in the world, but not exactly the hardest, either. Something that's been nagging at me, but being "shoved off into a corner" as not particularly relevant has finally reached the point where I can't push it aside anymore, and I think I've gotten to the point where I know how to ask the question that's been bothering me in a way that stands a chance of getting a useful answer. So here goes... I know that I create a thread, and as I do so, ...

  1. #1

    Default Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)


    I'm cruising along trying to write a program that uses threads. Not the
    simplest task in the world, but not exactly the hardest, either.
    Something that's been nagging at me, but being "shoved off into a
    corner" as not particularly relevant has finally reached the point where
    I can't push it aside anymore, and I think I've gotten to the point
    where I know how to ask the question that's been bothering me in a way
    that stands a chance of getting a useful answer. So here goes...

    I know that I create a thread, and as I do so, I specify (among other
    things) the routine where execution will begin, a pointer to a block of
    data the routine within the thread will use as input, and a pointer
    (perhaps unused, perhaps critically important) to any results the thread
    may want to return. Ferinstance:

    Result = NewThread(kCooperativeThread, /* The type of thread */
    MyRoutineForInsideTheThread, /* The routine */
    &ThreadInputParamStruct, /*The routine's input(s) */
    0, /* specifies default stack size */
    0, /* specifies no options set on thread creation */
    &MyThreadReturnStructPtr, /* The routine's output(s)*/
    &TheThradID);/* The ID of the thread created for me */


    Question 1:
    "MyRoutineForInsideTheThread()" is free to call *ANYTHING IT WANTS* -
    Toolbox routines, other functions within the program, etc. (For purposes
    of this question, ignore any potential "might be interrupt time, so
    can't call this", "Might be deferred task time, so can't call that",
    "The operation might move memory, so it can only be called at this
    time", and similar "conflicts".)

    True or false?

    If true, great...

    If false, my understanding is so hosed I probably need to go all the way
    back to square one and start again.

    Question 2:
    Considered as a monolithic unit (ignoring all considerations,
    particularly those of "when does it actually run?" that go along with
    threading, and further, ignoring the fact that
    "MyRoutineForInsideThread() would need to be defined/declared in a
    slightly different manner) the call above is functionally equivalant to
    this call:
    MyThreadReturnStructPtr=MyRoutineForInsideThread(T hreadInputParamStruct);

    True or false?

    Question 3:
    In the first call I illustratead above, when does
    MyRoutineForInsideTheThread() actually "return"? Is there some "magic" I
    need to do to cause it to finish executing? If so, I haven't been able
    to spot it, despite many re-readings (to be honest, many of them only
    partially understood) of the Thread Manager docs.

    I realize that a routine in a thread doesn't *REALLY* execute at the
    same time as the main thread, but I understand that as far as end
    results go, it might just as well be operating as if it were an entirely
    separate application, perhaps one which is running on an entirely
    separate machine. Is this understanding correct?

    My apologies for how awkward sounding this message probably is - At this
    time, I'm still groping around half-blind in my comprehension of threads
    and how to use them, and as such, I'm not even *REALLY* certain what
    questions I need to be asking, or in some cases, even HOW to ask them.
    Any assistance anyone cares to offer would be appreciated...

    --
    Don Bruder - net <--- Preferred Email - SpamAssassinated.
    Hate SPAM? See <http://www.spamassassin.org> for some seriously great info.
    I will choose a path that's clear: I will choose Free Will! - N. Peart
    Fly trap info pages: <http://www.sonic.net/~dakidd/Horses/FlyTrap/index.html>
    Don Guest

  2. #2

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    Don Bruder <net> wrote:
     

    You are using the "Thread Manager" which only supports Cooperative
    Threads. This means that you are pretty much allowed to do anything you
    want from within the thread. No need to worry about interrupt time, etc.

    You are probably thinking that your thread will be running preemptively,
    in which case, you *DO* need to worry about routines which are
    thread-safe. But to use Preemptive Threads you need to use the
    Multi-Processing API's or PThreads (Under MacOS X).
     

    Not really. When you call NewThread, you are setting up a thread to be
    ready to execute the next time you call YieldToAnyThread (or
    YieldToThread).
    It does not execute as soon as NewThread is called.
     

    It finishes executing when your thread-entry function exits.

    Typically, you'd have a loop in your thread-entry function which
    performs some long-ish task. Inside this loop, you'd call
    YieldToAnyThread to give up the CPU to other threads.
     

    Not really. The thing about threads is that within the same application,
    they all share the same memory space and have complete access to any
    global memory that any other thread in the same application has access
    to.

    They do each have their own run-time stacks though, which allows them to
    behave independantly as long as they don't get in each other's way.
     


    You have to keep in mind that when dealing with cooperative threads, you
    have to sprinkle calls to YieldToAnyThread through your code.
    This is what allows other cooperative threads to have the CPU.

    It doesn't work like Preemtive Threads where this is handled
    automatically for you.


    I'm sure you will receive replies telling you that the Thread Manager is
    depricated and you should be using the multiprocessing API's instead.
    It is NOT depricated. It is completely supported under MacOS X.

    But both types of threads are useful under different cirstances.

    --
    com http://www.mts.net/~gbeggs1/
    Gerry Guest

  3. #3

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    In article <1g71tt5.1o6uxj01j296vhN%com>,
    com (Gerry) wrote:
     
    >
    > You are using the "Thread Manager" which only supports Cooperative
    > Threads.[/ref]

    Right. Got that much out of reading the docs, even if it turns out that
    nothing else managed to "soak in" :)
     

    OK, this is good to know. However, it didn't *QUITE* answer my question.
    Which was probably phrased poorly to begin with...

    If I spawn a thread using NewThread, and the routine name I specify is
    "MyRoutineForInsideTheThread", I can call whatever I want from within
    MyRoutineForInsideTheThread, right? No restrictions of the general form
    "You didn't tell me that was part of your thread! You aren't allowed to
    do that!"

    Correct?

    Or, put another way, I've got umpty-six routines in the application
    besides RoutineForInsideOfThread. Once the thread that starts executing
    at RoutineForInsideOfThread gets going, I can call *ANY* of those
    umpty-six other routines, with no need to say "Hey, OS! This is part of
    a thread!"

    True or false?

    Side note:
    Please - No criticism intended, but it's probably going to sound that
    way no matter how I say it - I very specifically worded my questions as
    "true or false" in a deliberate attempt to overcome information overload
    and a mild (but incredibly annoying, at times) learning disability - If
    I ask a true/false question, PLEASE answer with a simple "true" or
    "false", and don't try to expand beyond what I've asked. If and when I
    think I understand things enough to ask for more details, I will. Right
    now, due to both my learning disability, and my current lack of
    understanding of the material I'm asking about, attempting to go beyond
    the scope of my questions is kinda like taking a toddler who can just
    barely walk across the room without face-planting into the coffee table
    and putting him on the balance beam at the olympics - Bet on it being a
    total disaster!
     

    I'm very carefully *NOT EVEN CONSIDERING* the MP APIs or PThreads at
    this point, and with my focus being on the thread manager method, I
    honestly don't want to know anything more about them. They exist. Beyond
    that, they're not relevant to me. Besides... I *KNOW* that mixing
    information about the various thread "flavors" would only cause
    nightmares for me! :)
     
    >
    > Not really. When you call NewThread, you are setting up a thread to be
    > ready to execute the next time you call YieldToAnyThread (or
    > YieldToThread).
    > It does not execute as soon as NewThread is called.[/ref]

    Right... I understand that. Which is why I specified ignoring the "when
    does it run" considerations. I'm aware that NewThread simply creates the
    thread, without actually running it, and that it sits there "dormant"
    until the next yielding function gets called. (and perhaps longer than
    that, if there are lots of other threads to be serviced in line ahead of
    my nice new one)

    The question was whether or not my second invocation method was a valid
    comparison to what happens when the new thread actually runs. I think
    that you actually answered that question in your response to the next
    question, whether you were meaning to or not.
     
    >
    > It finishes executing when your thread-entry function exits.[/ref]

    BINGO! There's a *HUGE* missing piece in the puzzle! Until now, I've
    been unable to figure out how/when/why a thread "returns".
     

    A bit too much information *RIGHT NOW*, but I *THINK* I see how it's
    going to be useful shortly. More reading and experimentaion is in
    order...
     
    >
    > Not really. The thing about threads is that within the same application,
    > they all share the same memory space and have complete access to any
    > global memory that any other thread in the same application has access
    > to.
    >
    > They do each have their own run-time stacks though, which allows them to
    > behave independantly as long as they don't get in each other's way.[/ref]

    Uhhh... The first paragraph I follow, and it seems to be saying "yes" to
    the question I *INTENDED* to ask, even if I ended up actually asking
    something else. The second is still a bit beyond my grasp of working
    with threads.
     
    >
    >
    > You have to keep in mind that when dealing with cooperative threads, you
    > have to sprinkle calls to YieldToAnyThread through your code.
    > This is what allows other cooperative threads to have the CPU.[/ref]

    Right, I'm aware of that factor. YieldToAnyThread for threaded programs
    is quite similar (not identical, by any standard, just quite similar) to
    WaitNextEvent in "flat" programs, and just like WaitNextEvent, needs to
    be called as often as reasonably possible to keep things running
    smoothly.
     

    Frankly, I just plain don't care whether it's supported under X or not.
    I'm writing my program *ON* a 9.1 system, *FOR* 9.1 and earlier (at
    least back to 8.5, perhaps back as far as 8.1) systems, and have
    absolutely no intention of, nor interest in, taking any action
    whatsoever aimed at making it X-compatible. If it turns out that it *IS*
    X-compatible if and when it gets finished, that's an unexpected bonus
    that I won't complain about. If it refuses to run on X, that's neither a
    surprise nor a disappointment. (At least to me...)

    --
    Don Bruder - net <--- Preferred Email - SpamAssassinated.
    Hate SPAM? See <http://www.spamassassin.org> for some seriously great info.
    I will choose a path that's clear: I will choose Free Will! - N. Peart
    Fly trap info pages: <http://www.sonic.net/~dakidd/Horses/FlyTrap/index.html>
    Don Guest

  4. #4

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    On Mon, 5 Jan 2004, Don Bruder wrote: 
    >
    > OK, this is good to know. However, it didn't *QUITE* answer my question.
    > Which was probably phrased poorly to begin with...
    >
    > If I spawn a thread using NewThread, and the routine name I specify is
    > "MyRoutineForInsideTheThread", I can call whatever I want from within
    > MyRoutineForInsideTheThread, right? No restrictions of the general form
    > "You didn't tell me that was part of your thread! You aren't allowed to
    > do that!"
    >
    > Correct?
    >
    > Or, put another way, I've got umpty-six routines in the application
    > besides RoutineForInsideOfThread. Once the thread that starts executing
    > at RoutineForInsideOfThread gets going, I can call *ANY* of those
    > umpty-six other routines, with no need to say "Hey, OS! This is part of
    > a thread!"
    >
    > True or false?[/ref]

    True, All functions are safe to use in cooperative threads.

    But false, in that you cannot blindly use functions in different threads.
    It is possible to trip yourself up, whenever you call YieldToAnyThread
    things globals or data that is shared with other threads can have been
    changed by one of your other threads. You need to be careful about tese
    things(of course this is all a lot easier with cooperative threads as you are guarenteed that this kind
    of thing won't happen behind your back, only when you call one of the
    yield functions).

     
    But often the answer is neither true or false really, but somewhere in
    between.
     
    > >
    > > Not really. When you call NewThread, you are setting up a thread to be
    > > ready to execute the next time you call YieldToAnyThread (or
    > > YieldToThread).
    > > It does not execute as soon as NewThread is called.[/ref]
    >
    > Right... I understand that. Which is why I specified ignoring the "when
    > does it run" considerations. I'm aware that NewThread simply creates the
    > thread, without actually running it, and that it sits there "dormant"
    > until the next yielding function gets called. (and perhaps longer than
    > that, if there are lots of other threads to be serviced in line ahead of
    > my nice new one)
    >
    > The question was whether or not my second invocation method was a valid
    > comparison to what happens when the new thread actually runs. I think
    > that you actually answered that question in your response to the next
    > question, whether you were meaning to or not.
    >[/ref]
    The same thing will happen to MyThreadReturnStructPtr, and the same
    calculatations/whatever will be performed by MyRoutineForInsideTheThread.
    The difference is of course the NewThread returns pretty much straight
    away, and the line after the call to NewThread will run way before
    MyRoutineForInsideTheThread has finished.
    MyThreadReturnStructPtr will only be touched later (ie a variable local
    to a function is often a bad candidate for MyRoutineForInsideTheThread,
    as it might not exist when the thread eventually returns.)

    Fred

    Frederick Guest

  5. #5

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    Don Bruder <net> wrote:
     

    Sorry. My newsreader truncated your subject line and I didn't notice
    that you specified "9.1/Classic/Pre-X" :)

    --
    com http://www.mts.net/~gbeggs1/
    Gerry Guest

  6. #6

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    In article
    <srcf.societies.cam.ac.uk>
    ,
    Frederick Cheung <DUH.ucam.org> wrote:
     
    > >
    > > OK, this is good to know. However, it didn't *QUITE* answer my question.
    > > Which was probably phrased poorly to begin with...
    > >
    > > If I spawn a thread using NewThread, and the routine name I specify is
    > > "MyRoutineForInsideTheThread", I can call whatever I want from within
    > > MyRoutineForInsideTheThread, right? No restrictions of the general form
    > > "You didn't tell me that was part of your thread! You aren't allowed to
    > > do that!"
    > >
    > > Correct?
    > >
    > > Or, put another way, I've got umpty-six routines in the application
    > > besides RoutineForInsideOfThread. Once the thread that starts executing
    > > at RoutineForInsideOfThread gets going, I can call *ANY* of those
    > > umpty-six other routines, with no need to say "Hey, OS! This is part of
    > > a thread!"
    > >
    > > True or false?[/ref]
    >
    > True, All functions are safe to use in cooperative threads.
    >
    > But false, in that you cannot blindly use functions in different threads.[/ref]

    Unless, of course, they're written to be safely reentrant... :)
     
    > But often the answer is neither true or false really, but somewhere in
    > between.[/ref]

    Perhaps, but as mentioned, it's a question of information overload - If
    I don't understand "X" and ask about it specifically, and instead of
    just saying "Yes, X does _______" or "No, X doesn't _________", you go
    off into Y, Z, and Q, then I get left in the dirt just as certainly as
    if I hadn't asked the question at all. When I think I've got a solid
    handle on X, I'll ask about Y, Z, and Q. Until I ask, chances are VERY
    high that discussion of anything other than "X" is likely to confuse me
    even worse. Like I said, it's a mild but annoying learning disability -
    I either pick it up in "standalone bite-sized pieces" that build on
    previous pieces, or I'm hopelesly lost. I envy those that can grab onto
    a whole wad of new information/concepts without the tedium of "This is
    "A". "A" does this. This is "B". "B" does that" that I have to go
    through to pick something up. But I've found through the years that if I
    try to deviate from the A to B to C to The Whole Thing learning path, I
    end up getting to "The Whole Thing" without having gained even a hint at
    a clue. I've learned to phrase my questions accordingly. As you've
    (hopefully) surmised, I'm no dummy, I just have to go about learning new
    things in a different way. Once learned, I can (and do) use the new
    stuff with at least reasonable competence. It's getting to the point of
    being able to do that which gives me headaches.

    <space-saving snip>
     

    OK, so let me see if I'm understanding this right:
    The only practical difference (aside from the "threaded/non-threaded"
    issue) between the two methods of invocation is when
    MyThreadReturnStructPtr's value "becomes valid" for each?

    As in: doing it the "NewThread" way means that MyThreadReturnStructPtr
    becomes valid "some unknown and unknowable amount of time in the
    future", while doing it as a direct invocation means "It's valid at the
    next line of code"?
     

    Nod-nod...
    That was a pitfall I've been on the lookout for (and doing my best to
    code around) from reading the docs. Not conceptually much different than
    the hazards of returning (or attempting to...) local vars from a "flat"
    routine - by the time whatever wants to use the returned values tries to
    do so, the values may have winked out of existence.

    What I was trying to sort out, in my own disjointed way, was whether or
    not a "newthread" call could be considered (ignoring the timing issues
    inherent in threaded vs non-threaded invocation) as equivalent to a
    non-thread invocation of whatever routine is named by NewThread's second
    parameter. It seems that actually is the case: A routine invoked by way
    of NewThread yields the same final result as invoking the routine
    directly, but there's no telling precisely WHEN it will yield that
    result, while a direct invocation means that the result is available and
    ready to use in the next line of code to be executed. Or have I gotten
    confused?

    --
    Don Bruder - net <--- Preferred Email - SpamAssassinated.
    Hate SPAM? See <http://www.spamassassin.org> for some seriously great info.
    I will choose a path that's clear: I will choose Free Will! - N. Peart
    Fly trap info pages: <http://www.sonic.net/~dakidd/Horses/FlyTrap/index.html>
    Don Guest

  7. #7

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    On Mon, 5 Jan 2004, Don Bruder wrote: 
    >
    > Unless, of course, they're written to be safely reentrant... :)[/ref]
    As long as you are aware of that kind of pitfall it's ok. 
    > > But often the answer is neither true or false really, but somewhere in
    > > between.[/ref]
    >

    >
    > OK, so let me see if I'm understanding this right:
    > The only practical difference (aside from the "threaded/non-threaded"
    > issue) between the two methods of invocation is when
    > MyThreadReturnStructPtr's value "becomes valid" for each?
    >
    > As in: doing it the "NewThread" way means that MyThreadReturnStructPtr
    > becomes valid "some unknown and unknowable amount of time in the
    > future", while doing it as a direct invocation means "It's valid at the
    > next line of code"?[/ref]
    yes. 
    >
    > Nod-nod...
    > That was a pitfall I've been on the lookout for (and doing my best to
    > code around) from reading the docs. Not conceptually much different than
    > the hazards of returning (or attempting to...) local vars from a "flat"
    > routine - by the time whatever wants to use the returned values tries to
    > do so, the values may have winked out of existence.
    >
    > What I was trying to sort out, in my own disjointed way, was whether or
    > not a "newthread" call could be considered (ignoring the timing issues
    > inherent in threaded vs non-threaded invocation) as equivalent to a
    > non-thread invocation of whatever routine is named by NewThread's second
    > parameter. It seems that actually is the case: A routine invoked by way
    > of NewThread yields the same final result as invoking the routine
    > directly, but there's no telling precisely WHEN it will yield that
    > result, while a direct invocation means that the result is available and
    > ready to use in the next line of code to be executed. Or have I gotten
    > confused?[/ref]
    No that's right.

    Fred

    Frederick Guest

  8. #8

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    In article
    <srcf.societies.cam.ac.uk>
    ,
    Frederick Cheung <DUH.ucam.org> wrote:
     
    > >
    > > Unless, of course, they're written to be safely reentrant... :)[/ref]
    > As long as you are aware of that kind of pitfall it's ok.[/ref]

    Yep, definitely aware. Happily enough, the code I'm playing with is,
    with very few exceptions, inherently reentrant, working specifically on
    pre-allocated and initialized data in a fully self-contained context
    struct that gets passed in on a per-invocation basis, and leaving the
    results in a similarly caller-provided output struct. I really don't
    think there's going to be a lot of problem with reentrancy, even across
    threads. At least, there SHOULDN'T be...
     
    > No that's right.[/ref]

    Excellent! Come, Igor! Back to the lab! Time to implement phase two of
    my dastardly plot to build a better mousetrap, and I'll need somebody to
    fetch me coffee and junkfood! :)

    --
    Don Bruder - net <--- Preferred Email - SpamAssassinated.
    Hate SPAM? See <http://www.spamassassin.org> for some seriously great info.
    I will choose a path that's clear: I will choose Free Will! - N. Peart
    Fly trap info pages: <http://www.sonic.net/~dakidd/Horses/FlyTrap/index.html>
    Don Guest

  9. #9

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    In article <lm3Kb.6597$sonic.net>,
    Don Bruder <net> wrote:
     
    >
    >Right. Got that much out of reading the docs, even if it turns out that
    >nothing else managed to "soak in" :)[/ref]

    Just a note that the Thread Manager does/did support preemptive threads
    on 68K machines (this may be relevant to your point below about target
    platforms).
     
    >
    >BINGO! There's a *HUGE* missing piece in the puzzle! Until now, I've
    >been unable to figure out how/when/why a thread "returns".[/ref]

    Bear in mind you can also force a thread to terminate before it reaches
    that point, by calling DisposeThread on it.

    If you do want to use this option, then you'll have to start worrying
    about cleaning memory allocations and other stuff that the thread might
    have done. The obvious way to deal with this is to install a
    ThreadTerminationProc, that should take care of it whether the thread
    runs to completion or not.
     
    >
    >The second is still a bit beyond my grasp of working
    >with threads.[/ref]

    Stacks are where local variables reside--when you declare a variable
    inside a routine and don't put "static" on the front. The main thing to
    worry about with stacks is that you can run out of space on them if you
    create local variables that are too large.
     [/ref]

    Not only that, but according to Technote 2028
    <http://developer.apple.com/technotes/tn/tn2028.html>, they are all
    implemented on top of the same underlying Mach threads architecture,
    which also means that threading is more expensive to use on OS X than on
    MacOS (9.x/8.x/7.x).
     

    Note that the Thread Manager is built into all versions of MacOS back to
    7.5, and was available as an add-in to earlier 7.x systems. If you want
    to run on pre-8.5 systems, that also opens the possibility of running
    your code on 68K machines, should you want to support that.
    Lawrence Guest

  10. Moderated Post

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    Removed by Administrator
    Kevin Guest
    Moderated Post

  11. Moderated Post

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    Removed by Administrator
    Michael Guest
    Moderated Post

  12. #12

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    In article <wave.co.nz>,
    Lawrence D'Oliveiro <gen.new_zealand> wrote:
     
    > >
    > >Right. Got that much out of reading the docs, even if it turns out that
    > >nothing else managed to "soak in" :)[/ref]
    >
    > Just a note that the Thread Manager does/did support preemptive threads
    > on 68K machines (this may be relevant to your point below about target
    > platforms).[/ref]

    I don't even want to mess around trying to mix the two flavors! If at
    all possible, I'll stick with the pure cooperative model unless and
    until I'm forced into doing the preemptive thing.
     
    > >
    > >BINGO! There's a *HUGE* missing piece in the puzzle! Until now, I've
    > >been unable to figure out how/when/why a thread "returns".[/ref]
    >
    > Bear in mind you can also force a thread to terminate before it reaches
    > that point, by calling DisposeThread on it.
    >
    > If you do want to use this option, then you'll have to start worrying
    > about cleaning memory allocations and other stuff that the thread might
    > have done. The obvious way to deal with this is to install a
    > ThreadTerminationProc, that should take care of it whether the thread
    > runs to completion or not.[/ref]

    As things stand at this point, anything I'm trying to do in a thread
    *SHOULD* (Beware of Mr. Murphy...) be operating only on data that gets
    passed in, with nothing being allocated within a thread - Everything,
    both inputs and outputs, is supposed to be pre-allocated and initialized
    by whoever calls the threaded stuff, with the threaded routines simply
    filling in the output data-block as needed.
     

    Right. The part I'm fuzzy about (and that the docs seem to take
    particular care not to mention) is "what's the default stack size?"
    There are references to setting a stack size of my choosing, and several
    mentions to the tune of "... is usually more than adequate..." in
    reference to the default thread stack size, but it seems like somebody
    went to a lot of effort when writing the docs to avoid actually saying
    what the default stack size actually is so that "Joe Programmer" can
    make a determination as to whether that's adequate, or he needs to jack
    the stack size up to get things working, or knock it back to avoid
    ing away resources that could be used for other things.
     

    Love to, but probably won't, since I'm *TRYING* to keep to the Carbon
    APIs as much as possible, and also need OpenTransport. Between these two
    factors, my "primary targets" are limited to 8.5, with a chance at
    getting things operational as far back as 8.1. Of coure, I'm actually
    writing it on a machine that's running 9.1, so that's my *REALLY*
    primary traget. If I can squeeze 7.5 in, that would be nice, but quite
    frankly, I don't see any pressing need to do so. If it "comes for free"
    due to my adhering to Carbon/OpenTransport specs, I'll write it up as a
    bonus :)

    --
    Don Bruder - net <--- Preferred Email - SpamAssassinated.
    Hate SPAM? See <http://www.spamassassin.org> for some seriously great info.
    I will choose a path that's clear: I will choose Free Will! - N. Peart
    Fly trap info pages: <http://www.sonic.net/~dakidd/Horses/FlyTrap/index.html>
    Don Guest

  13. Moderated Post

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    Removed by Administrator
    Lawrence Guest
    Moderated Post

  14. #14

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    In article <3nSKb.7150$sonic.net>,
    Don Bruder <net> wrote:
     

    Interestingly, there's an API call GetDefaultThreadStackSize to return
    this. There is also ThreadCurrentStackSpace to return the current free
    stack space for any thread.
     

    You're right. Could be because Apple reserves the right to change it in
    different system versions.
     

    Personally I find the Carbon APIs annoyingly restrictive. For example,
    the old SANE routines provide formatted conversions between strings and
    floating-point numbers that use Pascal-formatted strings (avoiding null
    terminators), and there seems to be no PowerPC-native equivalent to
    these. Luckily I have figured out how to call the appropriate SANE
    routines from PowerPC code, but of course this doesn't work under Carbon.
    Lawrence Guest

  15. #15

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    In article <wave.co.nz>,
    Lawrence DčOliveiro <gen.new_zealand> wrote:
     
    >
    > Interestingly, there's an API call GetDefaultThreadStackSize to return
    > this. There is also ThreadCurrentStackSpace to return the current free
    > stack space for any thread.

    >
    > You're right. Could be because Apple reserves the right to change it in
    > different system versions.[/ref]

    And I think Apple has changed it from release to release. If I'm
    remembering correctly, I think the default stack size was 512 KB on
    Jaguar and is 8 MB on Panther.

    On the other hand, I might be completely wrong. And I have no idea
    whether that applies to stack sizes for Thread Manager threads. Or how
    it applies to CFM. And Don doesn't care anyway, because he's only
    running on Mac OS 9. :)

    -Eric

    --
    Eric Albert stanford.edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  16. Moderated Post

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    Removed by Administrator
    Michael Guest
    Moderated Post

  17. #17

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    Eric Albert wrote: 

    You're right - I hadn't noticed this since upgrading to Panther:

    [powerbook:~] prussell% limit
    cputime unlimited
    filesize unlimited
    datasize 6144 kbytes
    stacksize 8192 kbytes
    coredumpsize 0 kbytes
    memoryuse unlimited
    descriptors 256
    memorylocked unlimited
    maxproc 100

    I have a number of apps with large stack sizes where I call setrlimit in
    main to explicitly set the stack size. I guess I should now change these
    to see what the initial stack size is first before modifying it.

    Paul

    Paul Guest

  18. #18

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    Lawrence D'Oliveiro <gen.new_zealand> wrote:
     

    I have a program which uses the old routines to convert doubles into
    Pascal strings in a Carbon application of mine.

    (This was before I was aware that CFString had a function which can
    convert a double into a string for me)

    I use dtox80 to convert the double into the old Extended format. That is
    the SANE format, isn't it?

    I get ahold of the number parts table with GetIntlResourceTable.
    Then I use ExtendedToString to convert the extended number to a
    formatted number string...

    Not exactly the most direct or easy way of doing a simple conversion
    from double to a string. But it is the old way of doing it, I think.
    And still works under MacOS X in my Carbon application.


    CFStringCreateWithFormat is probably the 'correct' way to do it under
    Carbon now though, which works much like printf-style formatting does
    except it takes into account international number formatting methods.

    --
    com http://www.mts.net/~gbeggs1/
    Gerry Guest

  19. #19

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    In article <1g7b7fr.1pm02qx1sk4w62N%com>,
    com (Gerry) wrote:
     
    >
    >I use dtox80 to convert the double into the old Extended format. That is
    >the SANE format, isn't it?[/ref]

    Yes it is.
     

    Yes, I'd forgotten about the Script Manager routines. But that gives you
    a localized conversion. I wanted a nonlocalized one.
    Lawrence Guest

  20. Moderated Post

    Default Re: Possibly *STOOOOPID* threads question (9.1/Classic/Pre-X)

    Removed by Administrator
    Kevin Guest
    Moderated Post

Page 1 of 2 12 LastLast

Similar Threads

  1. POE - THREADS - FORKS Question Need Help!
    By Phantazm in forum PERL Modules
    Replies: 1
    Last Post: November 3rd, 03:57 PM
  2. Possibly stupid question.....
    By Clive Sweeting in forum PHP Development
    Replies: 3
    Last Post: November 1st, 10:57 PM
  3. Replies: 2
    Last Post: September 10th, 03:21 PM
  4. A nagging Classic Question.
    By John in forum Mac Applications & Software
    Replies: 3
    Last Post: August 10th, 07:35 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139