David Abrahams wrote:
Well, I guess it's a C++ viewpoint vs a threads viewpoint. When I see "synchronous" cross-thread exceptions, cancel or otherwise, my first thought has to be, so who is responsible for the synchronization, and how does it work?"Meredith, Alisdair" <Alisdair.Meredith@xxxxxxxxxxxxxxxx> writes:David Abrahams [mailto:dave@xxxxxxxxxxxxxxxxxxxx] wrote:Subject to cancelability. In C++ "cancelability" would indicate whether cancellation points can throw (these asynchronously-initiatedexceptions).Sorry to jump into the middle of a good dialog with what might seem an irrelevance, but how will these asynchronous exceptions (now beingre-thrown 'as sychronous')Dave B: This is why I didn't want the term asynchronous in the discussion. It's just a confusing distraction.
The point is, though, that there IS no synchronization. That is, by definition, the communication protocol is asynchronous. (Actually, in pure POSIX cancellation is IS possible to "post" a cancel request without synchronization, unless you need to blast through a blocking operation. With a general cross-thread exception that's unlikely to be possible, but the synchronization is far below the application level, and provides no useful synchronous behavior for the application developer; which amounts to the same thing as "asynchronous".)
I can't possibly say "C++ does cross-thread exceptions synchronously", because it isn't a practical or useful definition, and wouldn't be a good operational model. The communication has to be asynchronous.
Only the final step, entirely within the target thread, is fully synchronous with that thread at a level that's of any use to the application model. The target detects at a cancellation/exception point that the request currently exists (registered asynchronously at some previous time ;-) ), and SYNCHRONOUSLY throws the exception into its own call stack.
So, yeah; the exception is synchronous. Fine. But that's only the final, and least interesting, step in the protocol. Or perhaps that's just "least interesting" to ME, because "I'm a thread guy". ;-)
begin:vcard fn:Dave Butenhof n:Butenhof;Dave org:Hewlett-Packard Company;Manageability Systems Lab adr;dom:110 Spit Brook Rd;;ZKO2-3/Q18;Nashua;NH;03062 email;internet:david.butenhof@xxxxxx title:HP Utility Pricing software agent Technical Lead tel;work:603.884.7460 note;quoted-printable:POSIX thread standards consultant=0D=0A= Author of "Programming With POSIX Threads" (Addison-Wesley)=0D=0A= Father to Amy (12) and Alyssa (8) x-mozilla-html:TRUE version:2.1 end:vcard