Re: Self-scheduling threading
Re: Self-scheduling threading
- Subject: Re: Self-scheduling threading
- From: Michael Koehmstedt <email@hidden>
- Date: Thu, 17 Mar 2005 15:22:37 -0800
I don't know
I am rather new to Cocoa development and unsure of its capabilities.
So if Cocoa can allow me to pause my thread's execution and restart at
a previously paused point (for resuming blocked IPCs/RPCs) without
resorting to the creation of extra threads, then I'd be happy to use
it because I'm sure it'd also provide the simplest solution as well.
Michael Koehmstedt
On Thu, 17 Mar 2005 17:44:58 -0500, Bob Ippolito <email@hidden> wrote:
>
> On Mar 17, 2005, at 17:25, Michael Koehmstedt wrote:
>
> > My framework has no need of OS scheduled-threads. There will only be
> > one thread per processor, so that no thread scheduling is done at all,
> > really. However, I need to be able to manage the time slices of these
> > threads, for efficient use of event-driven IPC/RPC.
> >
> > The framework is intended to, among other things, promote the use of a
> > certain kind of design pattern in order to eliminate or heavily reduce
> > the traditionally most expensive operations of a multi-threaded
> > application: context switching and lock contention.
> >
> > The result will be that developers can focus on the logic of their
> > application, and not have to worry about the underlying mechanisms.
> > Safe, efficient multithreading is not a trivial thing to add to any
> > application, and it is (or should be) completely separate from the
> > application's logic. That is what this framework is doing: providing
> > numerous underlying mechanisms, all tied closely together so that the
> > application developer can focus on what's really important for the
> > application and not have to reinvent the wheel every time.
> >
> > That is what I plan to gain by using explicitly scheduled fibers. It
> > is not a premature optimization, but a design choice.
>
> Without using a whole heck of a lot of magic macros, and/or some truly
> evil C stack slicing, I'm really not sure that what you're trying to do
> is even reasonable for Objective-C.
>
> A sane solution with the Least Magic Used would look just like what you
> already have in Foundation: a reactor (NSRunLoop), event sources
> (NSTimer, etc.), and event sinks (usually targets of the sources).
> There are certainly improvements that can be made there, though.
>
> In most event driven systems I've ever seen, you've got very few things
> Doing Work in every iteration of the run loop, so you've just got a
> bunch of sinks waiting for something to happen. When stuff does
> happen, round-robin works rather well. Time slicing is probably
> overkill, you can't pre-empt anyway. This is again basically what
> NSRunLoop/CFRunLoop does.
>
> What do you want to do that's any different/better than what's already
> there?
>
> -bob
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden