On system that does not provide blocking calls interruption (i.e. Windows), the deferred cancellation is emulated through a "controlled asyncrhonous cancellation". The thread is interrupted using immediate unkind cancellation: those systems provide a cancellation scheme that is able to kill a thread before it is ever rescheduled, or immediately if the system is a multiprocessor and the killer and the killed thread are running together on two processors. So, this aspect makes possible for the threads to safely state when they are in a condition that makes immediate cancellation possible. So, deferred cancellation is implemented by:
checking if a cancellation request has been issued,
if so, terminate the thread
if not, set a flag that singal that we can be canceled
do system call
reset the flag that signal that we can be canceled.
The killer will atomically check for that flag to be set in the killed thread; if that flag is not set, then the killer issue a kind cancellation request, while if it is set, the target thread is immediately killed.
Note:
The problem with killing another thread in a so unclean manner is that if the system call allocates internally heap memory, that memory is lost. So, even if we provide automatic emulated deferred cancellation points that seem to be safe at the moment, noting can ensure that the same low level functions that are safe now won't use heap memory in the future.
gethostbyname() это функция библиотеки, а не системный вызов.
-Maxim
exactly my point :) то что они добавили в висту - фактически useless,
для приложений которые работают HЕ с raw Win32 API. а таких API
собственно валом и без них в более-менее серьезных приложениях
никуда не деться .. так что хотели как лучше, а получилось как обычно
ajkj3em писал(а):exactly my point то что они добавили в висту - фактически useless,
для приложений которые работают HЕ с raw Win32 API. а таких API
собственно валом и без них в более-менее серьезных приложениях
никуда не деться .. так что хотели как лучше, а получилось как обычно
А на чем могут блокироваться "HЕ raw Win32 API" ? если не на raw Win32 API?
ajkj3em писал(а):exactly my point :) то что они добавили в висту - фактически useless,
для приложений которые работают HЕ с raw Win32 API. а таких API
собственно валом и без них в более-менее серьезных приложениях
никуда не деться .. так что хотели как лучше, а получилось как обычно
А на чем могут блокироваться "HЕ raw Win32 API" ? если не на raw Win32 API?
what kind of question is this ? :) естественно они блокируютcя в ядре,
где же еше. но ты ссылку то sobomax'ную посмoтрел бы для начала
и типа перепалку перечитал бы в контексте, а?
gethostbyname() это функция библиотеки, а не системный вызов.
exactly my point то что они добавили в висту - фактически useless,
для приложений которые работают HЕ с raw Win32 API. а таких API
собственно валом и без них в более-менее серьезных приложениях
никуда не деться .. так что хотели как лучше, а получилось как обычно
Не понял? gethostbyname() или его эквивалент в Win32 наверняка внутре использует простые I/O системные вызовы которые уже момно будет закенселить если что.
ну а как за'cancel'ить например shbrowseforfolder, когда он висит
пытаясь cчитать non-existent mounted share ? или IpRenewAddress
все тот же ? собственно, речь о том, что не все пишетcя на голом
Win32 API, так что пользы от вистовых изменений - практически ноль
ajkj3em писал(а):ну а как за'cancel'ить например shbrowseforfolder, когда он висит
пытаясь cчитать non-existent mounted share ? или IpRenewAddress
все тот же ? собственно, речь о том, что не все пишетcя на голом
Win32 API, так что пользы от вистовых изменений - практически ноль
Так если в том-же лилуксе ты какой-нибудь не-POSIX API вызовеш, типа для работы с mount points например, то тоже я очень сомневаюсь что у тебя получится его кансельнуть. Или например file I/O на недоступную NFS шару тоже очень может быть не получится закенселить.
Главное четко понимать что именно ты можеш закенселить а что нет. И тогда можно апликухи правильно писать.
ajkj3em писал(а):
what kind of question is this ? естественно они блокируютcя в ядре,
где же еше. но ты ссылку то sobomax'ную посмoтрел бы для начала
и типа перепалку перечитал бы в контексте, а?
Ну лана, лана, я типа работаю, западло msdn читать
Прочитал, понял, даа...
Ну хоть что-то можно кансельнуть стало, и то хорошо...
sobomax писал(а):
Главное четко понимать что именно ты можеш закенселить а что нет. И тогда можно апликухи правильно писать.
ну да ... дискусиия плавно перешла в констатацию непротиворечивых фактов ..
Кстати, а как было бы красиво это сделать?
Мне вот всегда хотелось для любого blocking io в thread-е иметь что-то типа SO_TIMEOUT. Типа время прошло, разблокируйся и узнай, что я по этому поводу думаю
И с возможностью продолжить ожидание с того же места
Marmot писал(а):
Мне вот всегда хотелось для любого blocking io в thread-е иметь что-то типа SO_TIMEOUT. Типа время прошло, разблокируйся и узнай, что я по этому поводу думаю
И с возможностью продолжить ожидание с того же места
