Recuperating after NS_HANDLER
-
I would like to do something like the following:
while(someStuff)
{
NS_DURING
something that could throw an exception
NS_HANDLER
handle it
NS_ENDHANDLER
}
I would like it to continue the loop even if it does reach an
exception, is this possible? This code above does not seem to be
working.
Francisco Tolmasky
<ftolmasky...>
http://www-scf.usc.edu/~tolmasky/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Why / how isn't it working (it should)?
j o a r
On 2004-05-16, at 09.59, Francisco Tolmasky wrote:
> I would like to do something like the following:
>
> while(someStuff)
> {
> NS_DURING
> something that could throw an exception
> NS_HANDLER
> handle it
> NS_ENDHANDLER
> }
>
> I would like it to continue the loop even if it does reach an
> exception, is this possible? This code above does not seem to be
> working.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 16 May 2004, at 08:59, Francisco Tolmasky wrote:
> I would like to do something like the following:
>
> while(someStuff)
> {
> NS_DURING
> something that could throw an exception
> NS_HANDLER
> handle it
> NS_ENDHANDLER
> }
>
> I would like it to continue the loop even if it does reach an
> exception, is this possible? This code above does not seem to be
> working.
It should work:
<marcel...>[Backup]cd /tmp/
<marcel...>[tmp]cat >exceptionTest.m
#import <Foundation/Foundation.h>
int main( int argc, char *argv[] )
{
int loops=20;
while ( loops-- > 0 ) {
id nsarray=[[NSMutableArray alloc] init];
NS_DURING
[nsarray addObject:nil];
NS_HANDLER
NS_ENDHANDLER
printf("%d loops remain\n",loops);
[nsarray release];
}
return 0;
}
<marcel...>[tmp]cc -Wall -O -o exceptionTest exceptionTest.m
-framework Foundation
<marcel...>[tmp]./exceptionTest 2>/dev/null
19 loops remain
18 loops remain
17 loops remain
16 loops remain
15 loops remain
14 loops remain
13 loops remain
12 loops remain
11 loops remain
10 loops remain
9 loops remain
8 loops remain
7 loops remain
6 loops remain
5 loops remain
4 loops remain
3 loops remain
2 loops remain
1 loops remain
0 loops remain
<marcel...>[tmp]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 16, 2004, at 12:59 AM, Francisco Tolmasky wrote:
> I would like to do something like the following:
>
> while(someStuff)
> {
> NS_DURING
> something that could throw an exception
> NS_HANDLER
> handle it
> NS_ENDHANDLER
> }
>
> I would like it to continue the loop even if it does reach an
> exception, is this possible? This code above does not seem to be
> working.
This is better:
do {
NS_DURING
while(someStuff) {
something that could throw an exception;
}
NS_HANDLER
handle it;
NS_ENDHANDLER
} while (someStuff);
Entering and exiting exception handlers carries a lot of overhead... ;)
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
It smells like a premature optimization to me...
j o a r
On 2004-05-16, at 15.45, Shaun Wexler wrote:
> This is better:_______________________________________________
>
> do {
> NS_DURING
> while(someStuff) {
> something that could throw an exception;
> }
> NS_HANDLER
> handle it;
> NS_ENDHANDLER
>
> } while (someStuff);
>
> Entering and exiting exception handlers carries a lot of overhead...
> ;)
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 16, 2004, at 7:41 AM, j o a r wrote:
> It smells like a premature optimization to me...
>
> j o a r
Yeah, that's what SHE said. It all adds up; not everyone has to worry
about things like this, but if they're writing a real-time
application... ;)
> On 2004-05-16, at 15.45, Shaun Wexler wrote:
>
>> This is better:
>>
>> do {
>> NS_DURING
>> while(someStuff) {
>> something that could throw an exception;
>> }
>> NS_HANDLER
>> handle it;
>> NS_ENDHANDLER
>>
>> } while (someStuff);
>>
>> Entering and exiting exception handlers carries a lot of overhead...
>> ;)
Even if it's just a few loop iterations, each time you enter an
exception block, it has to retrieve the current pthread to get the top
handler from the thread-specific data, then walk the list of handlers.
Then it adds this block to the linked list of exception blocks, and
changes the setjmp. That's expensive in many ways, especially if
objects in the loop throw often. The above example could be better
illustrated:
BOOL continueLoop = YES;
do {
NS_DURING
while(someStuff) {
something that could throw an exception;
}
continueLoop = NO;
NS_HANDLER
handle it;
if fatal err, set continueLoop = NO;
NS_ENDHANDLER
} while (continueLoop);
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Shaun,
On 16.5.2004, at 22:52, Shaun Wexler wrote:
> each time you enter an exception block, it has to retrieve the current
> pthread to get the top handler from the thread-specific data, then
> walk the list of handlers...
Does it? Why, on earth?!?
I admit I've never ever gdb'ed the thing so I don't know what happens
there, but I *did* implement my own NS_DURING/HANDLER macros many times
in different environments. Therefore, I *do* know that *nothing* is
needed but (a) allocate the stack frame buffer, (b) mark it with a
setjmp. All the other stuff (if any, and with ObjC without automatic
objects there is next to none!) can be solved only if the exception was
raised--if ever.
---
Ondra Hada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 16, 2004, at 4:04 PM, Ondra Cada wrote:
> On 16.5.2004, at 22:52, Shaun Wexler wrote:
>
>> each time you enter an exception block, it has to retrieve the
>> current pthread to get the top handler from the thread-specific data,
>> then walk the list of handlers...
>
> Does it? Why, on earth?!?
>
> I admit I've never ever gdb'ed the thing so I don't know what happens
> there, but I *did* implement my own NS_DURING/HANDLER macros many
> times in different environments. Therefore, I *do* know that *nothing*
> is needed but (a) allocate the stack frame buffer, (b) mark it with a
> setjmp. All the other stuff (if any, and with ObjC without automatic
> objects there is next to none!) can be solved only if the exception
> was raised--if ever.
Forgive me; I was referring to ObjC @try/@catch/@finally rather than
NS_HANDLER macros. Each form has its own evils. Regardless, there is
significant overhead which must be considered when using exception
handlers in moderate- to high-performance functions or methods, and
stack bloat (or overrun) can quickly occur with non-shallow recursion.
In any case, it's expensive to unnecessarily enter/exit exception
blocks within tight loops, which was the main point. ;)
--
Shaun Wexler
MacFOH
http://www.macfoh.com
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Aha, thanks. Truth is, being an old NeXTie I am used to NS_HANDLER et
al, and although I have noticed the docs and release notes, I know next
to nothing of those new directives.
Incidentally...
> I was referring to ObjC @try/@catch/@finally rather than NS_HANDLER
> macros
... are the differences between those two explained anywhere? So far I
have found no detailed explanation of potential (dis)advantages of
@try... vs. NS_HANDLER family, potential catches when mixing them, et
cetera. Just as well, is there a similar explanation/comparation of
NS...Lock vs. @synchronized?
TIA,
---
Ondra Hada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 16, 2004, at 5:45 PM, Ondra Cada wrote:
> Aha, thanks. Truth is, being an old NeXTie I am used to NS_HANDLER et
> al, and although I have noticed the docs and release notes, I know
> next to nothing of those new directives.
>
> Incidentally...
>
>> I was referring to ObjC @try/@catch/@finally rather than NS_HANDLER
>> macros
>
> ... are the differences between those two explained anywhere? So far I
> have found no detailed explanation of potential (dis)advantages of
> @try... vs. NS_HANDLER family, potential catches when mixing them, et
> cetera. Just as well, is there a similar explanation/comparation of
> NS...Lock vs. @synchronized?
NSLock will have more overhead than @synchronized(), which uses a hash
of the object's address as an index to a small shared pool of
pthread_mutex locks, and will be faster than NSLock in most cases.
When I wrote my own fine-grained locking functions, I compiled a fairly
accurately profile (pthread_mutex_lock does not include any
@synchronized macro overhead):
2 threads competing for the same lock:
Dual-1.42 1.42 GHz G4, one CPU disabled, SKWAtomicLock compiled for
G4-UP
SKWLock() - 38 ns per iteration
pthread_mutex_lock() - 312 ns per iteration
[NSLock lock] - 721 ns per iteration
SKWTryLock() - 40 ns per iteration - 1% miss percent
pthread_mutex_trylock() - 262 ns per iteration - 1% miss percent
[NSLock tryLock] - 510 ns per iteration - 1% miss percent
Dual-1.42 GHz G4, both CPU's enabled, SKWAtomicLock compiled for
G4-MP
SKWLock() - 99 ns per iteration
pthread_mutex_lock() - 6202 ns per iteration
[NSLock lock] - 7205 ns per iteration
SKWTryLock() - 112 ns per iteration - 8% miss percent
pthread_mutex_trylock() - 727 ns per iteration - 1% miss percent
[NSLock tryLock] - 651 ns per iteration - 26% miss percent
4 threads competing for the same lock:
Dual-1.42 1.42 GHz G4, one CPU disabled, SKWAtomicLock compiled for
G4-UP
SKWLock() - 32 ns per iteration
pthread_mutex_lock() - 772 ns per iteration
[NSLock lock] - 1460 ns per iteration
SKWTryLock() - 34 ns per iteration - 1% miss percent
pthread_mutex_trylock() - 275 ns per iteration - 1% miss percent
[NSLock tryLock] - 503 ns per iteration - 1% miss percent
Dual-1.42 GHz G4, both CPU's enabled, SKWAtomicLock compiled for
G4-MP
SKWLock() - 92 ns per iteration
pthread_mutex_lock() - 8914 ns per iteration
[NSLock lock] - 9887 ns per iteration
SKWTryLock() - 92 ns per iteration - 3% miss percent
pthread_mutex_trylock() - 739 ns per iteration - 1% miss percent
[NSLock tryLock] - 500 ns per iteration - 14% miss percent
YMMV. ;)
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 17 May 2004, at 1:56, Shaun Wexler wrote:
> On May 16, 2004, at 5:45 PM, Ondra Cada wrote:
>
>> Aha, thanks. Truth is, being an old NeXTie I am used to NS_HANDLER et
>> al, and although I have noticed the docs and release notes, I know
>> next to nothing of those new directives.
>>
>> Incidentally...
>>
>>> I was referring to ObjC @try/@catch/@finally rather than NS_HANDLER
>>> macros
>>
>> ... are the differences between those two explained anywhere? So far
>> I have found no detailed explanation of potential (dis)advantages of
>> @try... vs. NS_HANDLER family, potential catches when mixing them, et
>> cetera. Just as well, is there a similar explanation/comparation of
>> NS...Lock vs. @synchronized?
>
> NSLock will have more overhead than @synchronized(), which uses a hash
> of the object's address as an index to a small shared pool of
> pthread_mutex locks, and will be faster than NSLock in most cases.
> When I wrote my own fine-grained locking functions, I compiled a
> fairly accurately profile (pthread_mutex_lock does not include any
> @synchronized macro overhead):
Since j o a r seems to be away from the computer at the moment I feel
compelled to interject that the inclusion of any concrete timing
numbers on this list will be taken as smelling of premature
optimisation :-)
Nicko
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I'm still here, and I still think that this discussion - while
interesting for the cases where you're trying to optimize a section of
code of this type - is probably not at all interesting for the general
case. Benchmark first, optimize later. Clarity of code is key.
j o a r
On 2004-05-17, at 12.13, Nicko van Someren wrote:
> Since j o a r seems to be away from the computer at the moment I feel
> compelled to interject that the inclusion of any concrete timing
> numbers on this list will be taken as smelling of premature
> optimisation :-)
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
