[...прочитано...]
СМ>>>а вот например посадка самолета. кто полетит на нем, если его управление так написано. увольте! так что для студентов это сойдет, для реальных — ну это на вашей совести.
_FR>>Да, у меня интерес сугубо академический. Пытаюсь расширить кругозор и вооружиться на будущее.
СМ>а что тут академического. обычный программистский разговор. программа работать будет, сдать заказчику ее можно, но [...]
"Это не наш метод" (с)
СМ>если она вылетит в момент посадки самолета (читай переключния подстанции (для москвичей)), то что? совесть не будет мучать?
Конечно, будет, но, имхо, для _изучения_ полезно и то, что при некоторых, даже заранее известных, условиях не работет, потому что зачастую в таких проектах отдельные компоненты реализованы... как-то... интереснее что ли, чем в хорошо проверенной "железной" (если такие есть ) библитотеке и "оно" заставляет придаваться мечтам или дискуссиям о вкусной панацее.
under «*none*»,
... << RSDN@Home 1.1.4 beta 7 rev. 462>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Да уж , простым чтением-запуском там не обойтись, на первый взгляд подчти вся логика в __asm {...}
Чтоб отлаживаться (поглядеть что да как) поставь точку останова внутри __CxxFrameHandler (run to cursor не делай, исключения обрабатываются с заходом в kernel32 и не все методы отладки работают) кинь исключение и смотри что будет.
Вся логика в __CxxFrameHandlerInternal
А если попробовать вместо C++ исключений использовать SEH с кодом EXCEPTION_CONTINUE_EXECUTION ?
void _throw_remote_proc(DWORD nNumberOfArgs, const ULONG_PTR* args)
{
RaiseException(MY_REMOTE_EX_CODE, 0, nNumberOfArgs, args); // exception
}
// ........class ex
{
public:
int data;
public:
ex(): data(0)
{
}
ex(int _data): data(_data)
{
}
};
//bool ready = false;
//int ex_handler(int current_thread_state)
{
if (GetExceptionCode() == MY_REMOTE_EX_CODE)
{
LPEXCEPTION_POINTERS pp = GetExceptionInformation();
....
// report the thread state using `current_thread_state`
...
return EXCEPTION_CONTINUE_EXECUTION;
}
else
return EXCEPTION_CONTINIUE_SEARCH;
}
DWORD CALLBACK ThreadProc(LPVOID lpParam)
{
ready = true;
int current_thread_state = 0;__try
{
for(;)
{
current_thread_state++;
Sleep(1);
}
}
__catch (ex_handler(current_thread_state))
{
// Сюда никогда не попадаем
}
ready = true;
return 0;
}
//int main(int argc, char * argv[])
{
DWORD thread_id;
CloseHandle(CreateThread(NULL, 0, ThreadProc, NULL, 0, &thread_id));
while (!ready)
{
Sleep(1);
}
ex * e = new ex(10);
ready = false;
throw_remote(thread_id, e);
while (!ready)
{
Sleep(1);
}
return 0;
}
Раскритикуйте и это плиз.
По-моему этот вариант должен работать всегда кроме случаев когда поток уже находится в состоянии обработки SEH исключения.
Но эти куски кода можно защитить обернув блоки в которых можно кидать исключения "извне" критической секцией.
Здравствуйте, adontz, Вы писали:
A>Решение судя по всему кросс-компиляторное.
И определенно не кросс-платформенное. А надежное и кросс-платформенное, в том числе и кросс-компиляторное, решение предложил MaximE: Re: Межпотоковое кидание исключений
Здравствуйте, Andrew S, Вы писали:
AS>Гм, вообще то такие вещи можно делать при помощи APC. С блокирующими сокетами вполне работает на всей линейке вин32.
Т.е. пока поток ждёт в recv, он находится в алертабельном состоянии? Интересно. Это где-нибудь описано?
AS>>Гм, вообще то такие вещи можно делать при помощи APC. С блокирующими сокетами вполне работает на всей линейке вин32.
SH>Т.е. пока поток ждёт в recv, он находится в алертабельном состоянии? Интересно. Это где-нибудь описано?
А если серьезно — то официального описания этого бехавира я не встречал. Но тем не менее, apc вполне работают с блокирующими сокетами, причем, я практически уверен, что сокеты блокируются в alertable wait state специально (причем делается это явно в цикле, поскольку после выполнения apc вайт функция возвращается, надо проверить значение возврата и ждать наново). Поднимать исходники думаю смысла нет — скорее всего, найдем нечто вроде цикла с WaitForSingleObjectEx.
AS>>>Гм, вообще то такие вещи можно делать при помощи APC. С блокирующими сокетами вполне работает на всей линейке вин32.
SH>>Т.е. пока поток ждёт в recv, он находится в алертабельном состоянии? Интересно. Это где-нибудь описано?
AS>Да. http://gzip.rsdn.ru/Forum/Message.aspx?mid=1213466&only=1
Извиняюсь, что поднимаю древнюю тему, но, возможно, народу будет интересно узнать ответ на столь животрепещущий вопрос...
Итак, оказывается, это вполне документировано, но как обычно, размазано по нескольким частям msdn. Для затравки смотрим http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/sol_socket_socket_options.asp
опция SO_OPENTYPE.
#define SO_SYNCHRONOUS_ALERT 0x10
#define SO_SYNCHRONOUS_NONALERT 0x20
При создании сокета при помощи socket по умолчанию задается режим overlapped\alert (== 0), все остальные приведены выше. Изменить можно при помощи setsockopt, либо создавая сокет при помощи WSASocket. Т.о. описываемое выше поведение сокета является официально документированым, а, следовательно, его использование не только вполне безопасно, но и даже очень полезно.
Здравствуйте, Andrew S, Вы писали:
AS>Извиняюсь, что поднимаю древнюю тему, но, возможно, народу будет интересно узнать ответ на столь животрепещущий вопрос...
и вооружиться на будущее.
"Это не наш метод" (с)
) библитотеке и "оно" заставляет придаваться мечтам или дискуссиям о вкусной панацее.
