Netspirit писал(а):
В этом случае отличается логика работы метода "выполнить событие и дождаться завершения" - в другом случае может быть "выполнить событие (когда-то в будущем) не дожидаясь завершения". По-моему, это может вызвать проблемы порядка работы последующей схемы. Просто PostMessage можно отдельным методом, если нужно (типа, doSyncDeffered).
Да отличается. И должна отличаться. Хотя коды отличаются всего на 4 буквы.
Deferred Event это и есть "выполнить событие (когда-то в будущем) не дожидаясь завершения".
А Synchronize это "выполнить событие и дождаться завершения".
Разница мелодий в этой схеме:
Add(MainForm,2070834,91,91)
{
link(onCreate,2559580:doStart,[])
}
Add(Synchronize,16055947,329,105)
{
link(onSync,2849320:doEvent1,[])
}
Add(Thread,2559580,140,105)
{
link(onExec,16075278:doWork1,[])
link(onSyncExec,16075278:doWork2,[])
}
Add(CounterEx,16407686,413,105)
{
link(onNext,2070834:doCaption,[(452,111)(452,83)(81,83)(81,97)])
}
Add(Hub,7916229,294,105)
{
link(onEvent1,16055947:doSynchronize,[])
link(onEvent2,9846986:doBeep,[(319,118)(319,153)])
}
Add(Hub,2849320,378,105)
{
link(onEvent1,16407686:doNext,[])
link(onEvent2,3125880:doBeep,[(403,118)(403,153)])
}
Add(CheckBox,12700623,238,56)
{
Left=28
Top=21
Width=97
Caption="Deferred"
}
Add(Beep,9846986,329,147)
{
Freq=300
Duration=200
}
Add(Beep,3125880,413,147)
{
Freq=1300
Duration=200
}
Add(ChanelToIndex,16075278,189,105)
{
link(onIndex,1571423:doCompare,[])
}
Add(If_else,1571423,238,105)
{
link(onTrue,7916229:doEvent1,[])
link(Op1,12700623:Checked,[])
}
-- это правильно. Это вовсе не "проблемы порядка работы последующей схемы".
А именно так это все и задумывалось.
Netspirit, ты же doSynchronize не имеешь право вызывать в своем элементе из главного потока. Потому-что получишь DeadLock.
И еще надо будет разобраться "почему программа зависла", ведь DeadLock далеко не единственный способ повесить программу...
И предлагается "рабоче-крестьянская" логика: если ты не можешь дождаться завершения (потому что в главном потоке его завершение может быть только после твоего - а ты ждешь), то давай не будем ждать, и пускай делается само. Вообще-то, вполне разумное решение, при отсутствии альтернатив. И эта "другая логика" настолько небесполезна, что
nesco аж целый элемент для этого соорудил. В котором как и ты (как и Кладов) регистрировал сообщение, писал обработчик для окна, и т.п..
Поэтому непонятно, где ты увидел проблемы.
Как бы наоборот, повышается дуракоустойчивость - вместо DeadLock-а просто получаешь Deferred Event на выходе. С которым уже проще разобраться (программа то дышит, а не тупо висит).
Хотя, безусловно, программирование - это не для тех, кто работает методом тыка.
Netspirit писал(а):
У меня есть ещё такой вопрос.
У меня на это нет ответа. И вроде бы - и не может быть. Не документируют они это, оставляя за собой свободу действий. Есть слухи, гипотезы, некоторые соображения.
Предположим, что остались необработанные сообщения при получении WM_CLOSE. Это и сообщения какого-то таймера, и Deferred Events, и какое-то количество потоков, пытающихся синхронизироваться (хотя мне раньше казалось, что сообщения от SendMessage обрабатываются "вне очереди").
Если честно, я не увидел особого отличия необработанного WM_PAINT, от убийства потока безжалостным Terminate.
В подавляющем большинстве случаев.
Согласен, возможна более тонкая работа в потоках. Но мне непонятно, почему это должно быть общей парадигмой (мне показалось, что именно всеобъемлющая парадигма является Вашей головной болью в последнее время). В конце концов, кроме интернета существует много других интересных вещей.
Как надо это решать, мне думается...
Заводить отдельный сервер, в котором регистрируются особо чувствительные парни. И которые, соответственно, предоставляют ему метод "аккуратной остановки".
А сервер запускает процесс всех "аккуратных остановок", перехватив Close от MainForm.
Это все я говорил как бы про технологию менеджеров в HiAsm.
Редактировалось 6 раз(а), последний 2017-10-02 14:03:09
Поиск
Друзья
Администрация