Professional Web Applications Themes

Trying to figure out how to do this... - Mac Programming

I've got an app that has a group of inter-related routines that "get rolling" via a single call, and *MIGHT*, depending on runtime conditions, "lock up" the machine for as long as 90 seconds as they perform a complex task that needs to be accomplished (from the app's viewpoint) atomically, and *MUST* be completed before the next step in processing the data that these routines work on can be accomplished. At first glance, threading these routines seemed like a good plan, but after some experimentation along those lines, I find that solution to be unworkable. What I need to accomplish ...

  1. #1

    Default Trying to figure out how to do this...



    I've got an app that has a group of inter-related routines that "get
    rolling" via a single call, and *MIGHT*, depending on runtime
    conditions, "lock up" the machine for as long as 90 seconds as they
    perform a complex task that needs to be accomplished (from the app's
    viewpoint) atomically, and *MUST* be completed before the next step in
    processing the data that these routines work on can be accomplished. At
    first glance, threading these routines seemed like a good plan, but
    after some experimentation along those lines, I find that solution to be
    unworkable.

    What I need to accomplish is getting these routines to run to
    completion, while avoiding "locking up" the machine as they're running.
    in "straight toolbox" (as opposed to Carbon), I'd simply throw in some
    strategically-placed WaitNextEvent() calls, and go from there. In
    Carbon, I don't see a way to accomplish this.

    Anybody got a suggestion or three for me?

    Target: Carbon on 9.1. I have zero X-targeted development capability
    (hardware, software OR know-how to do it with)

    --
    Don Bruder - net - New Email policy in effect as of Feb. 21, 2004.
    I respond to Email as quick as humanly possible. If you Email me and get no
    response, see <http://www.sonic.net/~dakidd/main/contact.html> Short
    form: I'm trashing EVERYTHING that doesn't contain a password in the subject.
    Don Guest

  2. #2

    Default Re: Trying to figure out how to do this...

    In article <Hmsuc.14052$sonic.net>, Don Bruder
    <net> wrote:
     

    Excecute the 'complex task' in a separate MP Task. When it completes,
    post an 'I'm done' carbon event back to the main thread.
    Chris Guest

  3. #3

    Default Re: Trying to figure out how to do this...

    Don Bruder <net> wrote:
     

    A separate thread is cleanest (if everything you do is MP-safe), but why
    not stay with WaitNextEvent for your initial conversion and tune it up
    later?
    ward Guest

  4. #4

    Default Re: Trying to figure out how to do this...

    Don Bruder wrote: 

    By "in carbon," I take it you mean you're using the Carbon Event
    Manager? (You do know that WNE-style event loops still work, right?)

    Why not have strategically placed RunCurrentEventLoop() calls?

    --
    Pull out a splinter to reply.
    Peter Guest

  5. #5

    Default Re: Trying to figure out how to do this...

    In article <GtJuc.76716$news.prodigy.com>,
    Peter Ammon <com> wrote:
     
    >
    > By "in carbon," I take it you mean you're using the Carbon Event
    > Manager? (You do know that WNE-style event loops still work, right?)[/ref]

    I've read that they still work, but haven't figured out how to go about
    making them work when my program is written around the
    "RunMainEventLoop()" and "event handlers" model. Guess I've got some
    more reading to do...
     

    Ummm... Because I don't have a clue how to work with them at this point?
    <sigh> Just when you've got one technology figured out, Apple moves the
    goalposts, it seems...

    Couple other ideas kicking around in this thread that might work. I'm
    STILL looking at the idea of threading the offending routines, but that
    seems like a dead-end from my experiments so far. Although I did have a
    brainstorm last night (while I was at work, and therefore, unable to
    test it) about how to thread it "decently".

    Something like so:

    code
    code
    code
    code
    ThreadCodeFinished = false;
    StartLockuplikeProcessThread(); // Fire up the "Lockup" thread
    while (!ThreadCodeFinished)
    {
    YieldToAnyThread(); // Let the "lockup" thread run
    }
    NextStepInProcessing();
    code
    code
    code
    code

    ThreadCode:
    {
    while (!Done)
    {
    ProcessOneDataElement()
    YieldToAnyThread(); // Let the main (or any other) thread run
    }
    ThreadCodeFinished = true;
    }

    Now that I actually sit down and look at it, though, it appears it will
    have the same problem as my earlier experiments - The thread will be
    running, but the main program will still "play dead" (looking like a
    hard machine lockup) until ThreadCodeFinished gets set to true.

    That's what I'm trying to avoid - The whole "Oh crap, the machine has
    locked up/crashed" scenario that I'm currently facing. And when I say
    "hard lockup", I'm talking totally non-responsive to any input. Mouse
    cursor moves, but that's it. Clock freezes, updates don't happen, clicks
    and keypresses might as well not occur for all the impact they have,
    can't switch to another app, the whole nine yards - The machine is, for
    all intents and purposes, utterly dead until the processing I'm trying
    to do gets finished.

    The processing I'm doing involves several nested loops operating on a
    block of data that can and does vary in size depending on exact
    conditions at runtime - Might be one piece of data when the program
    first starts, in which case, the "dead time" is about 1-2 seconds to get
    it processed, or it might be operating on a dataset that has grown to
    1024 entries, in which case, the lockup seems to have a "top end"
    duration of just over 90 seconds.

    --
    Don Bruder - net - New Email policy in effect as of Feb. 21, 2004.
    I respond to Email as quick as humanly possible. If you Email me and get no
    response, see <http://www.sonic.net/~dakidd/main/contact.html> Short
    form: I'm trashing EVERYTHING that doesn't contain a password in the subject.
    Don Guest

  6. #6

    Default Re: Trying to figure out how to do this...

    In article <1gen350.1p52i2xe62n28N%com>,
    com (ward mcfarland) wrote:
     
    >
    > A separate thread is cleanest (if everything you do is MP-safe), but why
    > not stay with WaitNextEvent for your initial conversion and tune it up
    > later?[/ref]

    No "Conversion" involved... This is a "write it from scratch in Carbon"
    project.

    --
    Don Bruder - net - New Email policy in effect as of Feb. 21, 2004.
    I respond to Email as quick as humanly possible. If you Email me and get no
    response, see <http://www.sonic.net/~dakidd/main/contact.html> Short
    form: I'm trashing EVERYTHING that doesn't contain a password in the subject.
    Don Guest

  7. #7

    Default Re: Trying to figure out how to do this...

    dans l'article Hmsuc.14052$sonic.net, Don Bruder à
    net a écrit le 30/05/04 23:29:
     

    If you're running on OSX, just don't care. OSX is preemptively scheduled,
    which means other apps will run no matter what your app is doing.

    If you absolutely need to get this to run on OS 9, I strongly suggest that
    you use a MPTask to do the job, and call RunCurrentEventLoop() in a loop
    from you main thread until the job is finished.

    JobPending = true;
    StartTask();
    While(JobPending )
    {
    RunCurrentEventLoop(sometime);
    }

    And simply end your MPTask with :

    JobPending = false;

    Eric

    Eric Guest

  8. #8

    Default Re: Trying to figure out how to do this...

    In article <2kKuc.14258$sonic.net>,
    Don Bruder <net> wrote:
     

    MyAdjustUIForLongThread();
     

    WaitNextEvent(everyEvent, &e, NULL, 0); MyHandleEvent(e);
     

    MyRestoreUI();
     

    MyBumpProgressMeter();
     

    Your pseudocode was almost right, but missing some critical pieces that
    I have added.

    You need to set the User Interface appropriately as you enter the task.
    This means disabling menu commands that aren't applicable during the
    long task, and showing a per-app, per-doent, or per-window progress
    meter (whatever is appropriate for your application.)

    Since you are still processing events in your main loop, you'll still be
    handling update and activate events. Photoshop draws a checkerboard if
    it is asked to update a window while it is still rendering the window.
    David Guest

  9. #9

    Default Re: Trying to figure out how to do this...

    In article <sf.sbcglobal.net>,
    David Phillip Oster <org> wrote:


    OK, I see where you're going. Read on, please...
     
    >
    > MyAdjustUIForLongThread();[/ref]

    Hadn't thought of that...
    "The computer is not dead or on strike, it's just too busy to notice
    you're at the console. Give it a minute or two. Thanks!" :)
     
    >
    > WaitNextEvent(everyEvent, &e, NULL, 0); MyHandleEvent(e);[/ref]

    OUCH. This leaves me dinking around with events outside of the app's
    event loop. A prime consideration in my move to Carbon-targeted coding
    was getting out of needing to do that. Quite simply, I absolutely ADORE
    the concept of being able to say "InstallEventHandler(...)" a few times,
    then call RunApplicationEventLoop() and forget that events even exist
    'cause they get dealt with automagically. This looks like a major step
    backwards to the pre-carbon style WNE loop that was a major force in my
    migration to Carbon.

    Then again, it just dawned on me that this processing has to be able to
    happen BEFORE the main event loop gets fired (As part of initialization
    that gets done prior to the RunApplicationEventLoop() call), as well as
    afterwards... Hmmm... Looks like I haven't evaded WNE Hell after all :(
     
    >
    > MyRestoreUI();

    >
    > MyBumpProgressMeter();[/ref]

    Yeah... that's the ticket... Definitely a progress meter. Probably a
    barber-pole, since there's no predicting how exactly how long it's gonna
    take at any given invocation - I just know it's going to be "a while".
     
    >
    > Your pseudocode was almost right, but missing some critical pieces that
    > I have added.
    >
    > You need to set the User Interface appropriately as you enter the task.
    > This means disabling menu commands that aren't applicable during the
    > long task, and showing a per-app, per-doent, or per-window progress
    > meter (whatever is appropriate for your application.)
    >
    > Since you are still processing events in your main loop, you'll still be
    > handling update and activate events. Photoshop draws a checkerboard if
    > it is asked to update a window while it is still rendering the window.[/ref]

    --
    Don Bruder - net - New Email policy in effect as of Feb. 21, 2004.
    I respond to Email as quick as humanly possible. If you Email me and get no
    response, see <http://www.sonic.net/~dakidd/main/contact.html> Short
    form: I'm trashing EVERYTHING that doesn't contain a password in the subject.
    Don Guest

  10. #10

    Default Re: Trying to figure out how to do this...

    In article <PrTuc.14386$sonic.net>,
    Don Bruder <net> wrote:
     
    >
    > OUCH. This leaves me dinking around with events outside of the app's
    > event loop. A prime consideration in my move to Carbon-targeted coding
    > was getting out of needing to do that. Quite simply, I absolutely ADORE
    > the concept of being able to say "InstallEventHandler(...)" a few times,
    > then call RunApplicationEventLoop() and forget that events even exist
    > 'cause they get dealt with automagically. This looks like a major step
    > backwards to the pre-carbon style WNE loop that was a major force in my
    > migration to Carbon.
    >
    > Then again, it just dawned on me that this processing has to be able to
    > happen BEFORE the main event loop gets fired (As part of initialization
    > that gets done prior to the RunApplicationEventLoop() call), as well as
    > afterwards... Hmmm... Looks like I haven't evaded WNE Hell after all :([/ref]

    There is no reason that you can't call RAEL multiple times.

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  11. #11

    Default Sanity check? (was Re: Trying to figure out how to do this...)

    In article <PrTuc.14386$sonic.net>,
    Don Bruder <net> wrote:
     
    > >
    > > MyAdjustUIForLongThread();[/ref]
    >
    > Hadn't thought of that...
    > "The computer is not dead or on strike, it's just too busy to notice
    > you're at the console. Give it a minute or two. Thanks!" :)

    > >
    > > WaitNextEvent(everyEvent, &e, NULL, 0); MyHandleEvent(e);[/ref]
    >
    > OUCH. This leaves me dinking around with events outside of the app's
    > event loop. A prime consideration in my move to Carbon-targeted coding
    > was getting out of needing to do that. Quite simply, I absolutely ADORE
    > the concept of being able to say "InstallEventHandler(...)" a few times,
    > then call RunApplicationEventLoop() and forget that events even exist
    > 'cause they get dealt with automagically. This looks like a major step
    > backwards to the pre-carbon style WNE loop that was a major force in my
    > migration to Carbon.
    >
    > Then again, it just dawned on me that this processing has to be able to
    > happen BEFORE the main event loop gets fired (As part of initialization
    > that gets done prior to the RunApplicationEventLoop() call), as well as
    > afterwards... Hmmm... Looks like I haven't evaded WNE Hell after all :([/ref]

    Yeah, I know... following up myself is one of the first signs of Usenet
    insanity. What idiot ever claimed I was sane?!?!? :)

    But seriously...

    I'm going through the PDF "Handling Carbon Events", dated June 4, 2003
    on the first page, and showing "(C) 2004 Apple Computer Inc" in the
    footer of each page. I *HOPE* this is the "latest and greatest"...

    Looking at pages 15-17, and the discussion of WaitNextEvent(), it's
    sounding as though under Carbon, WNE behaves much like the event loop's
    usual handling, but only returns if a "regular" event (not a
    CarbonEvent) is found. Specifically, on page 16, there's the diagram of
    how WNE executes.

    "1. WaitNextEvent runs the event loop, placing events into the event
    queue as they appear. It also fires timers as neccesary."

    OK, clarification time - Does this mean that WNE under Carbon behaves
    almost like a single pass through the event loop each time it's called?
    That's what it SEEMS to be saying to me. (I'm deliberately ignoring the
    part about timers - Definitely outside my skill level ATM)

    "2. When an event appears in the event queue, WaitNextEvent dispatches
    it to the appropriate event target, but does not pull the event off the
    queue."

    "Dispatches it to the appropriate event target"... Does this mean that
    the handler that matches the event gets called? Or is this meaning to
    say that the event gets handed off to the item associated with it, for
    processing as it might see fit? IE, an Update event. Does that get
    passed to the window that's being updated as a command to update, or
    does it get passed to my (or the default, if I haven't installed one)
    update event handler?

    I'm tending to think it's getting passed to a handler, but I'm unclear.

    "3. If a Carbon event handler processes the event, then the event is
    pulled off the queue and WaitNextEvent waits for the next event."

    It sounds like this is telling me that in incoming event gets passed up
    the chain of handlers until either somebody handles it or it comes back
    unhandled. If it comes back handled, WNE pulls it from the queue, tosses
    it, and goes back to looking for an event.

    "4. If the event wasn't handled, WaitNextEventchecks to see if the event
    is in the event mask specified by the application. If not, it pulls the
    event off the queue and discards it."

    This seems to say that if it didn't get handled in the last step, and it
    isn't in the event mask, it gets dumped on the floor.

    "5. If the event is in the event mask, WaitNextEvent pulls the event
    from the queue, packages it as an event specification, and returns."

    On the other hand, if it wasn't handled, but it IS in the event mask, it
    gets returned to the caller as an "old style" event record, and this
    call to WaitNextEvent is complete.

    All of it seems to come together to say that when WNE is called, it
    loops until it gets an event. Once it gets an event, it passes it to
    whatever event handler routine is the target (This takes me into a whole
    other line of questions, but I don't think I'm ready to ask them yet)
    and if the handler returns EventNotHandledErr, checks the event against
    eh event mask, and if it's in the mask, returns a "regular" event
    record, otherwise, it pitches the event, and continues looping until the
    next event arrives, when it does the whole thing over again.

    Correct interpretation? Incorrect? Partly correct? Too off the wall for
    words?

    --
    Don Bruder - net - New Email policy in effect as of Feb. 21, 2004.
    I respond to Email as quick as humanly possible. If you Email me and get no
    response, see <http://www.sonic.net/~dakidd/main/contact.html> Short
    form: I'm trashing EVERYTHING that doesn't contain a password in the subject.
    Don Guest

  12. #12

    Default Re: Trying to figure out how to do this...

    On Mon, 31 May 2004, Eric VERGNAUD wrote:
     
    >
    > If you're running on OSX, just don't care. OSX is preemptively scheduled,
    > which means other apps will run no matter what your app is doing.[/ref]

    This is not strictly true. Not running an event loop is still frowned
    upon; witness the SpinControl app. The consequences are that your app is
    unresponsive, if you're Carbon then the windows can't be moved, windows
    and controls don't deactivate correctly, and people may think that it's
    crashed. Of course, this is still much better than what happens on OS 9
    when you do this, and locking up your app for a while in OS X is really
    just a minor blemish, not a major problem.
    Michael Guest

  13. #13

    Default Re: Trying to figure out how to do this...

    dans l'article twistedsys.net, Michael Ash à
    com a écrit le 1/06/04 13:34:
     
    >>
    >> If you're running on OSX, just don't care. OSX is preemptively scheduled,
    >> which means other apps will run no matter what your app is doing.[/ref]
    >
    > This is not strictly true. Not running an event loop is still frowned
    > upon; witness the SpinControl app. The consequences are that your app is
    > unresponsive, if you're Carbon then the windows can't be moved, windows
    > and controls don't deactivate correctly, and people may think that it's
    > crashed. Of course, this is still much better than what happens on OS 9
    > when you do this, and locking up your app for a while in OS X is really
    > just a minor blemish, not a major problem.[/ref]

    I 100% agree, however he did write: "locking up the machine", not the app.

    Eric

    Eric Guest

  14. #14

    Default Re: Trying to figure out how to do this...

    In article <BCE25FBB.22396%fr>,
    Eric VERGNAUD <fr> wrote:
     
    > >
    > > This is not strictly true. Not running an event loop is still frowned
    > > upon; witness the SpinControl app. The consequences are that your app is
    > > unresponsive, if you're Carbon then the windows can't be moved, windows
    > > and controls don't deactivate correctly, and people may think that it's
    > > crashed. Of course, this is still much better than what happens on OS 9
    > > when you do this, and locking up your app for a while in OS X is really
    > > just a minor blemish, not a major problem.[/ref]
    >
    > I 100% agree, however he did write: "locking up the machine", not the app.[/ref]

    And I also wrote that the program is being written and run on 9.1, not
    X. Pay attention, please, Eric. This little side-trip to nowhere useful
    is entirely due to you ignoring that very clearly stated fact. Seemingly
    for the sole purpose of allowing you a chance to "preach the gospel of
    MacOS X".

    --
    Don Bruder - net - New Email policy in effect as of Feb. 21, 2004.
    I respond to Email as quick as humanly possible. If you Email me and get no
    response, see <http://www.sonic.net/~dakidd/main/contact.html> Short
    form: I'm trashing EVERYTHING that doesn't contain a password in the subject.
    Don Guest

  15. #15

    Default Re: Trying to figure out how to do this...

    On Tue, 1 Jun 2004, Eric VERGNAUD wrote:

    [snip discussion of event loop on OS X] 

    Right, I just wanted to clarify that it's not entirely harmless. I think
    we're firmly in agreement.
    Michael Guest

  16. #16

    Default Re: Trying to figure out how to do this...

    On Tue, 1 Jun 2004, Don Bruder wrote:
     

    Two points.

    First, it's not a side-trip to nowhere. The universe does not revolve
    around you; it's likely that somebody reading this discussion will find it
    useful, even if you don't.

    Second, the other people on this group are humans, not machines. The
    discussion *will* drift from the original topic. Deal with it.
    Michael Guest

  17. #17

    Default Re: Trying to figure out how to do this...

    In article <twistedsys.net>,
    Michael Ash <com> wrote:
     
    >
    > Two points.
    >
    > First, it's not a side-trip to nowhere. The universe does not revolve
    > around you; it's likely that somebody reading this discussion will find it
    > useful, even if you don't.
    >
    > Second, the other people on this group are humans, not machines. The
    > discussion *will* drift from the original topic. Deal with it.[/ref]

    No wonder the world is going to hell in the proverbial handbasket! All
    these darn humans! :)

    --
    Don Bruder - net - New Email policy in effect as of Feb. 21, 2004.
    I respond to Email as quick as humanly possible. If you Email me and get no
    response, see <http://www.sonic.net/~dakidd/main/contact.html> Short
    form: I'm trashing EVERYTHING that doesn't contain a password in the subject.
    Don Guest

  18. #18

    Default Re: Trying to figure out how to do this...

    dans l'article 1U3vc.14460$sonic.net, Don Bruder à
    net a écrit le 1/06/04 20:27:
     

    I didn't 'ignore' it, I missed it. I'm not a preacher, and it's pretty rare
    to encounter a Mac OS 9 only development nowadays.

    Eric

    Eric Guest

  19. #19

    Default Re: Trying to figure out how to do this...

    On Tue, 1 Jun 2004, Don Bruder wrote:
     
    >
    > No wonder the world is going to hell in the proverbial handbasket! All
    > these darn humans! :)[/ref]

    So many problems would be easier without pesky humans. Things would be
    much less fun, though....
    Michael Guest

  20. #20

    Default Re: Trying to figure out how to do this...

    In article <twistedsys.net>,
    Michael Ash <com> wrote:
     
    > >
    > > No wonder the world is going to hell in the proverbial handbasket! All
    > > these darn humans! :)[/ref]
    >
    > So many problems would be easier without pesky humans. Things would be
    > much less fun, though....[/ref]

    Depends on your definition of fun... (And the humans you keep around...)

    --
    Don Bruder - net - New Email policy in effect as of Feb. 21, 2004.
    I respond to Email as quick as humanly possible. If you Email me and get no
    response, see <http://www.sonic.net/~dakidd/main/contact.html> Short
    form: I'm trashing EVERYTHING that doesn't contain a password in the subject.
    Don Guest

Similar Threads

  1. cant figure this out?
    By A.Bes in forum Macromedia Dynamic HTML
    Replies: 3
    Last Post: June 19th, 03:36 PM
  2. Trying to figure this out
    By dude9er webforumsuser@macromedia.com in forum Macromedia Flash Sitedesign
    Replies: 0
    Last Post: September 12th, 11:58 PM
  3. Can someone figure it out?
    By maxminas webforumsuser@macromedia.com in forum Macromedia Fireworks
    Replies: 5
    Last Post: August 19th, 09:28 AM
  4. trying to figure out CSS
    By Murray *TMM* in forum Macromedia Dreamweaver
    Replies: 1
    Last Post: July 17th, 07:59 AM

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