Re: alternatives to signals like try/catch
Re: alternatives to signals like try/catch
- Subject: Re: alternatives to signals like try/catch
- From: Terry Lambert <email@hidden>
- Date: Wed, 6 Oct 2010 21:49:27 -0700
On Oct 6, 2010, at 8:45 PM, Daniel Walter wrote:
> > However, you can certainly arrange to have exceptions delivered to your handler so that you can perform your own filtering. Your mistake is in assuming that you want to handle signals, which are not the primary delivery mechanism.
>
> What is the primary delivery mechanism? I have seen a reference to task_set_exception_ports somewhere, but have not found any real documentation of it.
Read section 9.7 of Amit Singh's book "Mac OS X Internals. A Systems Approach".
> Is this what you are talking about? Are signals layered on top of this?
Exceptions set the AST_BSD on the thread for a hardware exception, or if it's a software exception, then whatever thread it happens to land on. This then causes ast_taken() to call bsd_ast() on the thread, a function located in bsd/kern/kern_sig.c, which is the code that implements signals by calling postsig(), which calls sendsig(), which invokes the signal trampoline in libc up in user space.
Because the signal is delivered via an AST when the thread runs up to the user/kernel boundary, it's got a potentially large latency in delivery. It's also a persistent condition rather than an event.
I'll agree with Mike that you're not going to be able to do this selectively based on the code you are currently running in, and that you'll interfere with other things that try to grab the exception port -- for example, all debuggers.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden