Terminate called without an active exception

@squareroot · Регистрация: 19.10.2019

Студворк — интернет-сервис помощи студентам

При компиляции такого примера:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
class TestClass
{
public:
    TestClass()
    {
        auto func_ptr = &TestClass::Process;
        m_pthread = new std::thread(func_ptr, this);
    }
    ~TestClass() { delete m_pthread; }
private:
    void Process()
    {
          std::cerr << "run" <<  std::endl;
    }
    std::thread* m_pthread = nullptr;
};
 
int main(int argc, char *argv[])
{
    TestClass* ptc = new TestClass;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    delete ptc;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    std::cerr << "finished" << std::endl;
    return 0;
}

Возникает ошибка:

run
terminate called without an active exception
Press <RETURN> to close this window...

Т.е. текст finished даже не выводится.
Санитайзеры включены:
set (CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
set (CMAKE_LINKER_FLAGS_DEBUG "${CMAKE_LINKER_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
Но без них врде тоже самое.
Что я делаю не так ?

@DrOffset · 12.01.2020, 19:54

Сообщение от squareroot

Я не против его заново присоединить, на этопа его уничтожения, только как ?

Никак. Вы уже сказали через detach, что вас НЕ интересует дальнейшее управление потоком. Но потом вдруг выясняется, что все-таки оно вас интересует. Не находите здесь логического противоречия?
Вы можете обосновать зачем понадобилось его отсоединять?

@squareroot · 12.01.2020, 19:56 **[ТС]**

Сообщение от DrOffset

Никак. Вы уже сказали через detach, что вас НЕ интересует дальнейшее управление потоком. Но потом вдруг выясняется, что все-таки оно вас интересует. Не находите здесь логического противоречия?
Вы можете обосновать зачем понадобилось его отсоединять?

Мне нужно чтобы поток выполнялся не квазипараллельно, а параллельно основному потоку.
Но на этапе его уничтожения, я хочу вернуть контроль.

@DrOffset · 12.01.2020, 20:11

Сообщение от squareroot

Мне нужно чтобы поток выполнялся не квазипараллельно, а параллельно основному потоку.

Оно и так будет параллельно работать. Откуда вы это взяли?

Добавлено через 12 минут
Квазипараллельность выполнения зависит от железа и ОС, на уровне std::thread\pthread, вы никак на это не влияете. Состояние потока joinable - это не про квазипараллельность, это про контроль освобождения ресурсов.

If a thread is joinable, then another thread can call pthread_join(3) to wait for
the thread to terminate and fetch its exit status. Only when a terminated joinable
thread has been joined are the last of its resources released back to the system.

@squareroot · 12.01.2020, 20:14 **[ТС]**

Сообщение от DrOffset

Оно и так будет параллельно работать. Откуда вы это взяли?

Понял.
Вот только ваш пример некроссплатформенный в части pthread_testcancel();
pthread_cancel в винде я могу заменить TerminateThread(GetThreadID(), 0);
И тогда как быть pthread_testcancel(); ? Просто не использовать его в винде ?

@DrOffset · 12.01.2020, 20:36

Сообщение от squareroot

Понял.
Вот только ваш пример некроссплатформенный в части pthread_testcancel();
pthread_cancel в винде я могу заменить TerminateThread(GetThreadID(), 0);
И тогда как быть pthread_testcancel(); ? Просто не использовать его в винде ?

testcancel я использовал потому что std::thread поддерживает cancel только в так называемых cancellation points. Поэтому я поставил pthread_testcancel, чтобы создать такую точку.

Что касается винды, то можно использовать порт pthread - pthread_win32. Если вы используете mingw для компиляции для винды, то pthread, как правило, уже есть в комплекте.

Что касается TerminateThread, то ему все равно на пользовательский код внутри функции потока, он просто грохнет выполнение и все. В этом смысле эта функция более походит на pthread_kill c сигналом SIGKILL .

@squareroot · 12.01.2020, 21:48 **[ТС]**

Сообщение от DrOffset

testcancel я использовал потому что std::thread поддерживает cancel только в так называемых cancellation points. Поэтому я поставил pthread_testcancel, чтобы создать такую точку.

Что касается винды, то можно использовать порт pthread - pthread_win32. Если вы используете mingw для компиляции для винды, то pthread, как правило, уже есть в комплекте.

Что касается TerminateThread, то ему все равно на пользовательский код внутри функции потока, он просто грохнет выполнение и все. В этом смысле эта функция более походит на pthread_kill c сигналом SIGKILL .

Я сделал так:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
class TestClass
{
public:
    TestClass()
    {
        //m_active_flag_getter = m_active_flag_setter.get_future();
        auto func_ptr = &TestClass::Process;
        m_pthread = new std::thread(func_ptr, this);
        //m_pthread->detach();
    }
    ~TestClass()
    {
        pthread_kill(m_pthread->native_handle(), SIGKILL);
        m_pthread->join();
        delete m_pthread;
    }
    bool isRunning() const {return m_isRunning.load(); }
private:
    void Process()
    {
        std::cerr << "run" <<  std::endl;
 
        std::exception_ptr e_ptr;
        try
        {
            bool isRunn = isRunning();
            while(!isRunn)
            {
                isRunn = isRunning();
            }
        }
        catch(...)
        {
            e_ptr = std::current_exception();
        }
    }
    std::thread* m_pthread = nullptr;
    std::atomic_bool m_isRunning = false;
};
 
int main(int argc, char *argv[])
{
    TestClass* ptc = new TestClass;
    std::this_thread::sleep_for(std::chrono::milliseconds(10));
    delete ptc;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    std::cerr << "finished" << std::endl;
    return 0;
}

В итоге у меня завершается приложение после вызова delete ptc;, не отдельный поток.

Добавлено через 4 минуты
Пока не чувствую что я чемто управляю.

Добавлено через 14 минут
Впринцепи tgkill должен справится, но ему нужен самы родной природной хендл, а непосиксовый.

Добавлено через 41 секунду
А как его узнать снаружи потока ?

@DrOffset · 12.01.2020, 21:49

Сообщение от squareroot

Я сделал так:

Зачем? Вы прочитайте еще раз, что я вам написал.

@squareroot · 12.01.2020, 21:53 **[ТС]**

Сообщение от DrOffset

Зачем? Вы прочитайте еще раз, что я вам написал.

Затем что вариант с canselation point не особо нравится. В процедуре потока хочется обойтись без
#ifdef винда
...
#else линукс
...
#endif

Все эти примочки лучше в деструктор.

@DrOffset · 12.01.2020, 22:11

Сообщение от squareroot

Затем что вариант с canselation point не особо нравится.

1) Если у вас в процедуре потока не пустой цикл, то они там вероятнее всего и так будут.

Кликните здесь для просмотра всего текста

Cancellation points
POSIX.1 specifies that certain functions must, and certain other
functions may, be cancellation points. If a thread is cancelable,
its cancelability type is deferred, and a cancellation request is
pending for the thread, then the thread is canceled when it calls a
function that is a cancellation point.

The following functions are required to be cancellation points by
POSIX.1-2001 and/or POSIX.1-2008:

accept()
aio_suspend()
clock_nanosleep()
close()
connect()
creat()
fcntl() F_SETLKW
fdatasync()
fsync()
getmsg()
getpmsg()
lockf() F_LOCK
mq_receive()
mq_send()
mq_timedreceive()
mq_timedsend()
msgrcv()
msgsnd()
msync()
nanosleep()
open()
openat() [Added in POSIX.1-2008]
pause()
poll()
pread()
pselect()
pthread_cond_timedwait()
pthread_cond_wait()
pthread_join()
pthread_testcancel()
putmsg()
putpmsg()
pwrite()
read()
readv()
recv()
recvfrom()
recvmsg()
select()
sem_timedwait()
sem_wait()
send()
sendmsg()
sendto()
sigpause() [POSIX.1-2001 only (moves to "may" list in POSIX.1-2008)]
sigsuspend()
sigtimedwait()
sigwait()
sigwaitinfo()
sleep()
system()
tcdrain()
usleep() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
wait()
waitid()
waitpid()
write()
writev()

The following functions may be cancellation points according to
POSIX.1-2001 and/or POSIX.1-2008:

access()
asctime()
asctime_r()
catclose()
catgets()
catopen()
chmod() [Added in POSIX.1-2008]
chown() [Added in POSIX.1-2008]
closedir()
closelog()
ctermid()
ctime()
ctime_r()
dbm_close()
dbm_delete()
dbm_fetch()
dbm_nextkey()
dbm_open()
dbm_store()
dlclose()
dlopen()
dprintf() [Added in POSIX.1-2008]
endgrent()
endhostent()
endnetent()
endprotoent()
endpwent()
endservent()
endutxent()
faccessat() [Added in POSIX.1-2008]
fchmod() [Added in POSIX.1-2008]
fchmodat() [Added in POSIX.1-2008]
fchown() [Added in POSIX.1-2008]
fchownat() [Added in POSIX.1-2008]
fclose()
fcntl() (for any value of cmd argument)
fflush()
fgetc()
fgetpos()
fgets()
fgetwc()
fgetws()
fmtmsg()
fopen()
fpathconf()
fprintf()
fputc()
fputs()
fputwc()
fputws()
fread()
freopen()
fscanf()
fseek()
fseeko()
fsetpos()
fstat()
fstatat() [Added in POSIX.1-2008]
ftell()
ftello()
ftw()
futimens() [Added in POSIX.1-2008]
fwprintf()
fwrite()
fwscanf()
getaddrinfo()
getc()
getc_unlocked()
getchar()
getchar_unlocked()
getcwd()
getdate()
getdelim() [Added in POSIX.1-2008]
getgrent()
getgrgid()
getgrgid_r()
getgrnam()
getgrnam_r()
gethostbyaddr() [SUSv3 only (function removed in POSIX.1-2008)]
gethostbyname() [SUSv3 only (function removed in POSIX.1-2008)]
gethostent()
gethostid()
gethostname()
getline() [Added in POSIX.1-2008]
getlogin()
getlogin_r()
getnameinfo()
getnetbyaddr()
getnetbyname()
getnetent()
getopt() (if opterr is nonzero)
getprotobyname()
getprotobynumber()
getprotoent()
getpwent()
getpwnam()
getpwnam_r()
getpwuid()
getpwuid_r()
gets()
getservbyname()
getservbyport()
getservent()
getutxent()
getutxid()
getutxline()
getwc()
getwchar()
getwd() [SUSv3 only (function removed in POSIX.1-2008)]
glob()
iconv_close()
iconv_open()
ioctl()
link()
linkat() [Added in POSIX.1-2008]
lio_listio() [Added in POSIX.1-2008]
localtime()
localtime_r()
lockf() [Added in POSIX.1-2008]
lseek()
lstat()
mkdir() [Added in POSIX.1-2008]
mkdirat() [Added in POSIX.1-2008]
mkdtemp() [Added in POSIX.1-2008]
mkfifo() [Added in POSIX.1-2008]
mkfifoat() [Added in POSIX.1-2008]
mknod() [Added in POSIX.1-2008]
mknodat() [Added in POSIX.1-2008]
mkstemp()
mktime()
nftw()
opendir()
openlog()
pathconf()
pclose()
perror()
popen()
posix_fadvise()
posix_fallocate()
posix_madvise()
posix_openpt()
posix_spawn()
posix_spawnp()
posix_trace_clear()
posix_trace_close()
posix_trace_create()
posix_trace_create_withlog()
posix_trace_eventtypelist_getnext_id()
posix_trace_eventtypelist_rewind()
posix_trace_flush()
posix_trace_get_attr()
posix_trace_get_filter()
posix_trace_get_status()
posix_trace_getnext_event()
posix_trace_open()
posix_trace_rewind()
posix_trace_set_filter()
posix_trace_shutdown()
posix_trace_timedgetnext_event()
posix_typed_mem_open()
printf()
psiginfo() [Added in POSIX.1-2008]
psignal() [Added in POSIX.1-2008]
pthread_rwlock_rdlock()
pthread_rwlock_timedrdlock()
pthread_rwlock_timedwrlock()
pthread_rwlock_wrlock()
putc()
putc_unlocked()
putchar()
putchar_unlocked()
puts()
pututxline()
putwc()
putwchar()
readdir()
readdir_r()
readlink() [Added in POSIX.1-2008]
readlinkat() [Added in POSIX.1-2008]
remove()
rename()
renameat() [Added in POSIX.1-2008]
rewind()
rewinddir()
scandir() [Added in POSIX.1-2008]
scanf()
seekdir()
semop()
setgrent()
sethostent()
setnetent()
setprotoent()
setpwent()
setservent()
setutxent()
sigpause() [Added in POSIX.1-2008]
stat()
strerror()
strerror_r()
strftime()
symlink()
symlinkat() [Added in POSIX.1-2008]
sync()
syslog()
tmpfile()
tmpnam()
ttyname()
ttyname_r()
tzset()
ungetc()
ungetwc()
unlink()
unlinkat() [Added in POSIX.1-2008]
utime() [Added in POSIX.1-2008]
utimensat() [Added in POSIX.1-2008]
utimes() [Added in POSIX.1-2008]
vdprintf() [Added in POSIX.1-2008]
vfprintf()
vfwprintf()
vprintf()
vwprintf()
wcsftime()
wordexp()
wprintf()
wscanf()

2) Также при использовании pthread_win32 надобность в #ifdef винда отпадет.

3) Также можно использовать boost::thread вместо std::thread - он может прерывать потоки.
https://www.boost.org/doc/libs... terruption

4) Также можно сделать прослоечную функцию, в которой активировать флаг PTHREAD_CANCEL_ASYNCHRONOUS через pthread_setcancelstate, чтобы pthread_cancel работал без cancellation points. (функция нужна, чтобы оставить вашу основную процедуру потока без платфомозависимых вызовов).

Использования функций жесткого завершения может привести к потере ресурсов или оставления ресурсов (например мьютексов) в некорректном состоянии. Нужно стараться избегать их всеми средствами.

@squareroot · 12.01.2020, 22:22 **[ТС]**

Сообщение от DrOffset

1) Если у вас в процедуре потока не пустой цикл, то они там вероятнее всего и так будут.

2) Также при использовании pthread_win32 надобность в #ifdef винда отпадет.

3) Также можно использовать boost::thread вместо std::thread - он может прерывать потоки.
https://www.boost.org/doc/libs... terruption

4) Также можно сделать прослоечную функцию, в которой активировать флаг PTHREAD_CANCEL_ASYNCHRONOUS через pthread_setcancelstate, чтобы pthread_cancel работал без cancellation points. (функция нужна, чтобы оставить вашу основную процедуру потока без платфомозависимых вызовов).

Использования функций жесткого завершения может привести к потере ресурсов или оставления ресурсов (например мьютексов) в некорректном состоянии. Нужно стараться избегать их всеми средствами.

Ну этот код не связан с какйто конкретной задачей.
В реальной обёртке предусметрено несколько путей завершения потока.
Но деструктор должен уметь грохать поток, когда он не хочет завершаться по хорошему.
pthread_win32 не имеет сильной поддержки. АПИ у винды немного поменяется в новой версии и у мингвешников не скоро дойдут руки поменять свой сурогат.
Когда поток надо завершить принудительно, никакие прослойки могут не помочь.

Добавлено через 7 минут
Когда поток не хочет завершаться по хорошему, на потерю ресурсов при принудительном завершении можно не бращать внимание.

@DrOffset · 12.01.2020, 22:39

Сообщение от squareroot

на потерю ресурсов при принудительном завершении можно не бращать внимание.

Тогда и на корректную работу приложения тоже можно не обращать внимания после этого. Если вас это устраивает - пожалуйста.

Сообщение от squareroot

Но деструктор должен уметь грохать поток, когда он не хочет завершаться по хорошему.

Вот именно, когда. А вы по умолчанию пытаетесь впихнуть самый жесткий метод, о чем я вас и предупредил.

В остальном, я вам дал достаточно вариантов.

@squareroot · 12.01.2020, 22:43 **[ТС]**

Сообщение от DrOffset

Тогда и на корректную работу приложения тоже можно не обращать внимания после этого. Если вас это устраивает - пожалуйста.

Вот именно, когда. А вы по умолчанию пытаетесь впихнуть самый жесткий метод, о чем я вас и предупредил.

В остальном, я вам дал достаточно вариантов.

Дак я уже три раза сказал, что код обстрагирован от реальной задачи. Тут просто прорабатываю самый жёский вариант, но в реальном коде конечно сначало будет попытка "договарится по хорошему"
Вариантов недостаточно, потомучто поток может зависнуть в месте которое не имеет отношение к cancelation point.

@DrOffset · 12.01.2020, 22:46

Вообще потоки, когда вероятной ситуацией является зависание, обычно не используют. Потому что их принудительное завершение всегда чревато потерей стабильности. Т.е. после такого завершения потока, разделяемые ресурсы уже будет невозможно привести к корректному состоянию, как, впрочем, и гарантированно узнать, что они в нем находятся. Единственное что можно сделать - это завершить весь процесс и перезапуститься.
Поэтому в подобных системах, когда зависание - частая ситуация, применяют процессы, и управляют ими через какой-либо вариант IPC. Пример такой системы - браузер, где каждая вкладка - отдельный процесс, именно из-за угрозы зависания.

Добавлено через 41 секунду

Сообщение от squareroot

Вариантов недостаточно, потомучто поток может зависнуть в месте которое не имеет отношение к cancelation point.

Вариантов достаточно. Пункт 4) как раз об этом.

@squareroot · 12.01.2020, 22:51 **[ТС]**

Сообщение от DrOffset

Вообще потоки, когда вероятной ситуацией является зависание, обычно не используют. Потому что их принудительное завершение всегда чревато потерей стабильности. Т.е. после такого завершения потока, разделяемые ресурсы ужебудет невозможно привести к корректному состоянию, как, впрочем, и гарантированно узнать, что они в нем находятся. Единственное что можно сделать - это завершить весь процесс и перезапуститься.
Поэтому в подобных системах, когда зависание - частая ситуация, применяют процессы, и управляют ими через какой-либо вариант IPC. Пример такой системы - браузер, где каждая вкладка - отдельный процесс, именно из-за угрозы зависания.

Добавлено через 41 секунду

Вариантов достаточно. Пункт 4) как раз об этом.

В ваших словах много правды, но я стремлюсь сделать обёртку которая будет убивать поток всегда, при любых обстоятельствах.
4й пункт не годиться потомучто неизвестно где поток зависнет. Я рассматриваю обёртку над std::thread как свой маленький sdk, поэтому мне надо чтоб он был универсален и надёжен.

@DrOffset · 12.01.2020, 22:58

Сообщение от squareroot

4й пункт не годиться потомучто неизвестно где поток зависнет.

Ну и что? Вы включаете асинхронное прерывание в самом начале и дальше уже без разницы где он завис.

@squareroot · 13.01.2020, 00:40 **[ТС]**

Сообщение от DrOffset

Ну и что? Вы включаете асинхронное прерывание в самом начале и дальше уже без разницы где он завис.

С неменьшим успехом поток может узнать свой tid и сообщить его наружу, чтобы в плохой ситуации деструктор обёртки вызвал tgkill. Тут вопрос "торга" какое решение лучше. Оба решение имеют свои prons & cons.

Добавлено через 1 час 20 минут

Сообщение от DrOffset

Ну и что? Вы включаете асинхронное прерывание в самом начале и дальше уже без разницы где он завис.

Не могу понять в чём дело.
В рабочем коде интегрировал 4й вариант.
Но после вызова имею:

C++
1
2
3
4
5
6
7
ASAN:DEADLYSIGNAL
=================================================================
==4789==ERROR: AddressSanitizer: SEGV on unknown address 0xffffffffffffffff (pc 0x7fc8463d76b3 bp 0x7fc8428feb30 sp 0x7fc8428fe2a0 T1)
==4789==The signal is caused by a WRITE memory access.
    #0 0x7fc8463d76b2 in __pthread_setcanceltype (/lib/x86_64-linux-gnu/libpthread.so.0+0xf6b2)
    #1 0x7fc84683496f  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x4596f)
    #2 0x56309b4f77eb in ThreadFeatures<void (TTestBench::*)(TTestBench::TDummy*, TTestBench::TDummy&), TTestBench, TTestBench::TDummy*, std::reference_wrapper<TTestBench::TDummy> >::threadFunction(void (TTestBench::*)(TTestBench::TDummy*, TTestBench::TDummy&), TTestBench*, TTestBench::TDummy*, std::reference_wrapper<TTestBench::TDummy>)

На тестовом коде прокатывает.

@DrOffset · 13.01.2020, 00:48

squareroot, покажите как вызывается pthread_setcanceltype у вас.

@squareroot · 13.01.2020, 00:55 **[ТС]**

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
template <class Func, class Class, typename... Args>
void ThreadFeatures<Func, Class, Args...>::threadFunction(Func _func,
                                                    Class * _obj,
                                                    Args... _args) noexcept
{
   const char * funcname = __FUNCTION__;
   std::exception_ptr e_ptr;
   bool bisRunning = false;
   std::cerr << "point2" << std::endl;
 
#if  defined(_POSIX_THREADS)
   int * oldtype;
   auto code = pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS,
                                     oldtype);
   //if (code != 0) throw thread_errors(thread_errors::error_launch);
#endif
 
   try
   {
      std::cerr << "point3" << std::endl;
....................

До отображения point3 дело не доходит.

Добавлено через 3 минуты
А, всё дошло. Я думал функция выдалет память под олдтайп.

@DrOffset · 13.01.2020, 00:55

squareroot,

C++
1
2
3
   int oldtype;
   auto code = pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS,
                                     &oldtype);

@squareroot · 13.01.2020, 01:24 **[ТС]**

DrOffset, Я правильно понимаю что нижеследущий код означает, что pthread_cancel может привести к краху приложения, если он будет вызван в момент работы обработчика исключения процедуры потока ?

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
class TestClass
{
public:
    TestClass()
    {
        m_active_flag_getter = m_active_flag_setter.get_future();
        auto func_ptr = &TestClass::Process;
        m_pthread = new std::thread(func_ptr, this);
        //m_pthread->detach();
    }
    ~TestClass()
    {
        //m_active_flag_getter.wait_for(
        //            std::chrono::milliseconds(200)
        //);
        //bool result = !isActive();
        pthread_cancel(m_pthread->native_handle());
        m_pthread->join();
        delete m_pthread;
    }
    //bool isActive() const noexcept { m_active_flag_getter.valid(); }
    bool isRunning() const {return m_isRunning.load(); }
private:
    void Process()
    {
        int * oldstate;
        auto code = pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, oldstate);
 
        std::cerr << "run code:";
        //std::cerr <<  code << std::endl;
 
        std::exception_ptr e_ptr;
        try
        {
            throw "error";
            bool isRunn = isRunning();
            while(!isRunn)
            {
                isRunn = isRunning();
                //pthread_testcancel();
            }
 
            //m_active_flag_setter.set_value_at_thread_exit();
        }
        catch(...)
        {
            e_ptr = std::current_exception();
            while(1) {}
        }
    }
    std::thread* m_pthread = nullptr;
    std::promise<void> m_active_flag_setter;
    std::future<void> m_active_flag_getter;
    std::atomic_bool m_isRunning = false;
};
 
int main(int argc, char *argv[])
{
    TestClass* ptc = new TestClass;
    std::this_thread::sleep_for(std::chrono::milliseconds(100));
    //std::cerr << "flag:" << ptc->isActive() << std::endl;
    delete ptc;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    std::cerr << "finished" << std::endl;
    return 0;
}

Новые блоги и статьи Все статьи Все блоги /
Как замкнутый ядерный цикл решит проблему недостатки фосфора? Био миграция фосфора со дна океана anaschu 26.06.2026 Биологический лифт: Концепция подъема фосфора со дна океана с помощью ЗЯТЦ Предлагаю на обсуждение альтернативу тяжелому промышленному бурению океанического дна. Вместо сложной инженерии мы можем. . .	сукцессия 5 anaschu 26.06.2026 ПЛАН РАЗРАБОТКИ математической модели сукцессии микоризных систем Переход AM → EcM (Endo + ErM) · Шумилов А. С. · ИФХиБПП РАН · Пущино · 2026 . . .	сукцессия 4 anaschu 25.06.2026 Более детализированный план разработки План доработки модели динамики микоризных симбиозов (EcM с гистерезисом) Цель: Реализовать логику переключения между эрикоидным (ErM) и эктомикоризным. . .	сукцессия 3 anaschu 25.06.2026 Примерный план работ по модели
сукцессия 2 anaschu 25.06.2026 параметризировочная калибровочная таблица будущей модели	Многофункциональное здание: как одно здание порождает конфликты требований, которые никто не планировал (мат мет мод 29) anaschu 23.06.2026 Многофункциональное здание: как одно здание порождает конфликты требований, которые никто не планировал Материалы для обсуждения с МГСУ · 2026 Рисунки внутри приложенного ворд файла. Что за. . .	28. Конкретное развертывание плана номер 1 из поста номер 27 anaschu 22.06.2026 Можно ли из модели получить конкретные строительные требования? Честно — напрямую из текущей модели такие ответы не получить. Но цепочка логики есть, и она не такая длинная. Где разрыв . . .	27. Планы на разработку функциональных требований к строительству внутри модели пищеблока (или не только его?) anaschu 22.06.2026 Что уже реализовано и даёт конфликты «бесплатно» Самый простой конфликт уже работает — конфликт за ресурс-работника. Заданий больше, чем доступных поваров → очередь в queue1. Это прямое отражение. . .

@DrOffset 19501 / 10106 / 2461 Регистрация: 30.01.2014 Сообщений: 17,825
	13.01.2020, 00:48
	squareroot, покажите как вызывается pthread_setcanceltype у вас. 0