Re: -forceCancel an NSOperation

> On Mar 1, 2017, at 3:10 PM, Carl Hoefs wrote: > > This is a multi-tasking server of sorts that runs different analysis > algorithms on demand depending on what's requested. But much of the > algorithmic code is "hostile" (i.e., student code) so it's

Re: -forceCancel an NSOperation

> On Mar 1, 2017, at 2:56 PM, Doug Hill wrote: >> >> On Mar 1, 2017, at 2:44 PM, Wim Lewis wrote: >> > On Mar 1, 2017, at 2:32 PM, Ken Thomases wrote: Very sound reasoning, all. Thanks much for your insights! This is a

Re: -forceCancel an NSOperation

> On Mar 1, 2017, at 2:44 PM, Wim Lewis wrote: > > On Mar 1, 2017, at 2:23 PM, Carl Hoefs wrote: >> Normally, that is sufficient. But under some circumstances, it's possible >> for an executing NSOperation to get hung up doing I/O or for

Re: -forceCancel an NSOperation

On Mar 1, 2017, at 2:23 PM, Carl Hoefs wrote: > Normally, that is sufficient. But under some circumstances, it's possible for > an executing NSOperation to get hung up doing I/O or for some other reason. > No means is given to forcibly stop the execution of an

Re: -forceCancel an NSOperation

On Mar 1, 2017, at 4:23 PM, Carl Hoefs wrote: > > The NSOperation -cancel and NSOperationQueue -cancelAllOperations methods > merely set a property that needs to be periodically and cooperatively checked > and acted upon by the receiving NSOperation. > >

-forceCancel an NSOperation

The NSOperation -cancel and NSOperationQueue -cancelAllOperations methods merely set a property that needs to be periodically and cooperatively checked and acted upon by the receiving NSOperation. Normally, that is sufficient. But under some circumstances, it's possible for an executing

Re: macOS 10.13 suggestion for init() throws

> On Feb 28, 2017, at 4:26 PM, Jens Alfke wrote: > > >> On Feb 28, 2017, at 11:56 AM, Daryle Walker > > wrote: >> >> The problem here is an interface mismatch where Swift has function >> throw-ability status out-of-band from that