Thread cancelation
Jakob Erber
My question is, whether thread cancelation is really an option for
implementing something like a quality of service framework, like CORBA
specifies. What I mean, is threads cancelation really reliable and portable
enough to be used for middleware products.
That the Java language actually does not support thread cancelation anymore
might be an indicator, that thread cancelation is not a good choice in
critical environments.
Any opinions to that?
Jakob
--
What I publish in this group, is to be understood as my personal opninion
and must not be interpreted as a official statement of my company
Alexander Terekhov
[...]
> That the Java language actually does not support thread cancelation anymore
> might be an indicator, that thread cancelation is not a good choice in
> critical environments.
Gee! ... how about this:
http://www.rtj.org/rtsj-V1.0.pdf
"The interrupt() method in java.lang.Thread provides
rudimentary asynchronous communication by setting a
pollable/resettable flag in the target thread, and
by throwing a synchronous exception when the target
thread is blocked at an invocation of wait(), sleep(),
or join(). This specification extends the effect of
Thread.interrupt() and adds an overloaded version in
RealtimeThread, offering a more comprehensive and
non-polling asynchronous execution control facility.
It is based on throwing and propagating exceptions
that, though asynchronous, are deferred where necessary
in order to avoid data structure corruption."
http://gee.cs.oswego.edu/dl/concurrency-interest/aims.html
"Thread class API review
Among other issues, we should discuss whether to
tackle clean-up of interruption mechanics. The two
main considerations are Should interruption be
distinguished from cancellation? Should users be
given control over asynchronous interruption?
(supported for example via a simplified version
of RTSJ capabilities). "
Also, I would like to invite anyone who is
doing threaded C++ programming to participate
in the following C++/threads discussion:
http://groups.google.com/groups?as_umsgid=3C7BD6B3.1EAE29D0%40web.de
("and async-cancel!)-safety" does NOT mean that *everything*
should be async-cancel-safe)
More info:
http://groups.google.com/groups?as_umsgid=3C73CB8B.E764D3C6%40web.de
*PLUS*:
http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_PDF/ARH9MBTE.PDF
(*respectable* calling standard with "nonlocal GOTO in
a multilanguage environment" ;-) exceptions/signals, etc.)
http://www.codesourcery.com/cxx-abi/abi-eh.html
("C++ ABI for Itanium: Exception Handling")
http://www.codesourcery.com/cxx-abi/exceptions.pdf
(HP's "aC++ A.01.15 - Public version")
regards,
alexander.
Jakob Erber
--
What I publish in this group, is to be understood as my personal opninion
and must not be interpreted as a official statement of my company
"Jakob Erber" <erb...@post.ch> schrieb im Newsbeitrag
news:3c7cb721$1...@news.post.ch...