🚀 go-pugleaf

Tom Payne wrote:
> 
> The second major need is to allow a signal to force an exception in
> without the program polling for it.

I guess we'll just disagree on this ... I see signals as basically
asynchronous, and exceptions as wholly synchronous.  Plus, exactly
which exceptions are legal will vary depending on the state of the
thread's execution (i.e. the "throw" specification of the function
being executed).  So it doesn't make sense to me to mix the two.

If you want signals to cause exceptions, it's simple enough to code
the handoff between signal handling thread and the exception-raising
one ... either sigwait() and pthread_cond_signal(), or else use the
older asynchronous signal handlers and a semaphore.  The thread that
blocked on the synchronization variable (sema_t or pthread_cond_t)
raises whatever exception it wants.


> 	In a thread on this
> topic a couple months ago, David Chase gave an implementation strategy
> based on range tables that seemed to involve no CPU overhead and whose
> complexity seemed reasonable.

But if the exceptions aren't synchronous, the complexity of generating
those tables can become extremely high ... particularly in conjunction
with the code motion performed as part of most optimizations.  As was
pointed out to me by David himself.
-- 
David Brownell
http://www.netcom.com/~brownell
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]