On Wed, Dec 17, 2008 at 11:14 AM, Keith Duncan wrote:
>
> On 17 Dec 2008, at 15:41, Jean-Daniel Dupas wrote:
>
>>> because there's absolutely no way to guarantee that only a single
>>> NSOperationQueue
>>> exists in your process
>
> Couldn't you swizzle +[NSOperationQueue alloc] to return a single
Le 17 déc. 08 à 17:14, Keith Duncan a écrit :
On 17 Dec 2008, at 15:41, Jean-Daniel Dupas wrote:
because there's absolutely no way to guarantee that only a single
NSOperationQueue
exists in your process
Couldn't you swizzle +[NSOperationQueue alloc] to return a
singleton? Sure it's a h
There are a great many more bugs than what Mike described in the
previous thread relating to NSOperationQueue - it leaks Mach Ports
under GC, it occasionally will retain an operation object if you
cancel before starting it, it will sometimes dealloc an operation
object without updating fini
On 17 Dec 2008, at 15:41, Jean-Daniel Dupas wrote:
because there's absolutely no way to guarantee that only a single
NSOperationQueue
exists in your process
Couldn't you swizzle +[NSOperationQueue alloc] to return a singleton?
Sure it's a hack, but a simple one that can be #ifdefed out fo
Le 17 déc. 08 à 16:29, Michael Ash a écrit :
On Wed, Dec 17, 2008 at 4:49 AM, Jean-Daniel Dupas
wrote:
Le 17 déc. 08 à 10:32, Jean-Daniel Dupas a écrit :
And before you go off using NSOperationQueue, you should be aware
that
it's broken on Leopard, as described in this thread:
http://w
On Wed, Dec 17, 2008 at 4:49 AM, Jean-Daniel Dupas
wrote:
>
> Le 17 déc. 08 à 10:32, Jean-Daniel Dupas a écrit :
>
> And before you go off using NSOperationQueue, you should be aware that
>
> it's broken on Leopard, as described in this thread:
>
> http://www.cocoabuilder.com/archive/message/cocoa
Le 17 déc. 08 à 10:32, Jean-Daniel Dupas a écrit :
And before you go off using NSOperationQueue, you should be aware
that
it's broken on Leopard, as described in this thread:
http://www.cocoabuilder.com/archive/message/cocoa/2008/10/30/221452
We already discuss this issues, and I agree
Le 17 déc. 08 à 04:27, Michael Ash a écrit :
On Tue, Dec 16, 2008 at 5:19 PM, Bradley S. O'Hearne
wrote:
All,
Thanks to everyone for the replies. In my code, I made an error --
overrode
the start method rather than the main method. After I overrode the
start
method, everything worked gre
On Dec 16, 2008, at 8:27 PM, Michael Ash wrote:
And before you go off using NSOperationQueue, you should be aware that
it's broken on Leopard, as described in this thread:
http://www.cocoabuilder.com/archive/message/cocoa/2008/10/30/221452
And if anyone wants a second opinion, we've been us
On Tue, Dec 16, 2008 at 5:19 PM, Bradley S. O'Hearne
wrote:
> All,
>
> Thanks to everyone for the replies. In my code, I made an error -- overrode
> the start method rather than the main method. After I overrode the start
> method, everything worked great. Without trying to get too specific on the
On Dec 16, 2008, at 2:19 PM, Bradley S. O'Hearne wrote:
The reason this is useful is that rather than have this code
scattered within an application which needs it, I can instead make a
generic utility class out of it (which I've now done) and can reuse
it anywhere. In my case, I was creati
All,
Thanks to everyone for the replies. In my code, I made an error --
overrode the start method rather than the main method. After I
overrode the start method, everything worked great. Without trying to
get too specific on the actual issue, the more general thrust of my
original questio
On Tue, Dec 16, 2008 at 9:29 AM, Brad O'Hearne
wrote:
> Hello,
>
> I am trying to create an NSThread subclass which completely wraps the
> desired behavior of the thread execution.
I am sorry but what you described isn't making sense to me so I really
don't know how to answer your question. Can y
On Tue, Dec 16, 2008 at 10:49 AM, Jean-Daniel Dupas
wrote:
> No. In Cocoa you never subclass NSThread. Instead of overriding start, you
> implement you own start wherever you want (and with the name you want) and
> you pass it as parameter (SEL + target).
Pre-Leopard that we true, as of Leopard
Le 16 déc. 08 à 18:29, Brad O'Hearne a écrit :
Hello,
I am trying to create an NSThread subclass which completely wraps
the desired behavior of the thread execution. Now typically when
creating a new thread instance, it seems one will use the
initWithTarget:selector:object initializer to
On Dec 16, 2008, at 11:29 AM, Brad O'Hearne wrote:
I am trying to create an NSThread subclass which completely wraps
the desired behavior of the thread execution.
I don't understand what you're trying to say here.
Why is overriding the -main method not sufficient? That's what's
suggested
On Dec 16, 2008, at 9:29 AM, Brad O'Hearne wrote:
Is this the recommended approach, or is there another way to go
about this?
Have you considered using NSOperation / NSOperationQueue? From what
you're saying I think that would be the preferred building block for
this type of thing start
17 matches
Mail list logo
