• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: self release
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: self release


  • Subject: Re: self release
  • From: Shaun Wexler <email@hidden>
  • Date: Mon, 12 May 2003 22:17:34 -0700

On Monday, May 12, 2003, at 10:26 AM, Wolfgang Ante wrote:

Yes, I have noticed that!

Well, my idea is to have a quite independent object that does things in the background (and is kept alive either with timers or with threads) and when it is finished it kills itself.

Like writing something like...

[[[MyWorkingBee alloc] initWithWorkDesc:info] runInBackground];

...and then not caring about it any more.

Bad idea?

I have a cool class, called ThreadedJob. I don't want to release or open source it just yet (still adding to it, no namespace prefix, etc), but you can have a copy if you need to get something cranked out in a hurry. It works very well.

A "job" is a unit of work that needs to be done, but each job is an object itself, similar to an NSInvocation, but it carries a lot more state information and is intended for larger chunks of work. It can be scheduled, repeated, everything but killed (I'll add that feature soon), etc. I haven't even begun to add all of the functionality into it that I want, it's fairly simple, but rudely fast, and will probably do what you want. All jobs are queued from a managed pool of worker threads, which creates and destroys threads as needed based on number of processors, usage and load (and no more than one killed per 5 seconds), with one persistent scheduler thread. No distributed objects, or anything.

Instead of worrying about an object, and its lifespan, you could simply do this:

[[ThreadedJob jobWithSelector:@selector(doSomeWork) forTarget:aTarget] perform];

And forget about it...

Of course, the ThreadedJob class is much more powerful that that. I create several semi-atomic jobs for certain objects, and just call them like an invocation. The beauty of this is that you don't need NSTimers or a NSRunLoop to get timer behavior, and it's all done with background threads.

[[ThreadedJob jobWithSelector:@selector(doSomeWork) forTarget:aTarget] performAfterDelay:1.0];

A more advanced example:

kickTheBeehive_job = [[ThreadedJob jobWithSelector:@selector(doSomeWork) forTarget:aTarget withObject:anObject didEndSelector:@selector(didSomeWork) didEndTarget:someoneWhoCares] retain];

if ([kickTheBeehive_job isScheduled]) {
[kickTheBeehive_job dequeue];
[kickTheBeehive_job setPerformInterval:5.0];
[kickTheBeehive_job schedule];
}
else if ([kickTheBeehive_job isCompleted] && beesCameOut) {
[kickTheBeehive_job suspend];
[runLikeHell_job performASAP];
}

And more!

Regards,
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: self release (From: Wolfgang Ante <email@hidden>)

  • Prev by Date: Re: Sharing preferences between applications
  • Next by Date: Re: Document proxy icon
  • Previous by thread: Re: self release
  • Next by thread: Re: self release
  • Index(es):
    • Date
    • Thread