Terminate called without an active exception

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

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

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

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;
}

Новые блоги и статьи Все статьи Все блоги /
Kafka или Pulsar: Что лучше для потоковой обработки в Java Javaican 14.03.2025 Среди множества решений для потоковой обработки данных Apache Kafka долгое время удерживала лидирующие позиции, став де-факто стандартом в индустрии. Однако в последние годы всё больше внимания. . .	Создание и использование компонентов в Vue 3 Reangularity 14.03.2025 Компонент в Vue - это автономный блок интерфейса, который содержит собственную разметку, логику и стили. Представьте себе кнопку, форму ввода или даже целую панель навигации - всё это можно оформить. . .	Vue 3: Создаем современное веб-приложение с Composition API Reangularity 14.03.2025 В фронтенд-разработке Vue 3 выделяется своим прагматичным подходом. В отличие от React с его минималистичной философией "всё — JavaScript" или Angular с его всеобъемлющим корпоративным подходом, Vue. . .	Разработка контекстных меню в iOS mobDevWorks 14.03.2025 С приходом iOS 13 Apple представила новый API для контекстных меню, который полностью заменил предыдущую технологию 3D Touch peek & pop. Хотя многие разработчики и пользователи испытывают ностальгию. . .	Лучшие практики оптимизации Docker Image Mr. Docker 13.03.2025 Размер Docker-образа влияет на множество аспектов работы с контейнерами. Чем больше образ, тем дольше его загрузка в реестр и выгрузка из него. Для команд разработки, работающих с CI/ CD пайплайнами,. . .
Вопросы на собеседовании по Docker Mr. Docker 13.03.2025 Ты сидишь напротив технического специалиста, и вдруг звучит вопрос про Docker Swarm или многоэтапные сборки. Пот на лбу? Не переживай, после этой статьи ты будешь готов ко всему! Эта статья будет. . .	Поиск текста в сносках : замена дефиса на тире или тире на дефис... РоΜа 13.03.2025 Нужно было найти текст в сносках и заменить. Почему-то метод селекшн не сработал. . . пришлось гуглить. найденный на форумвба код пришлось править. Смысл - заменяет в сносках дефисы и тире на нужные. . . .	Real PATH definitions in bash scripts jigi33 13.03.2025 Как поймать путь и путь к директории относительно запускаемого файла в BASH 1. поймать путь через вывод $(pwd) 2. более правильно - на основе realpath (см. скриншот)	Django или Flask: что выбрать для веб-разработки на Python py-thonny 13.03.2025 Django – это высокоуровневый фреймворк, который придерживается философии "всё включено". Он предоставляет разработчику готовые решения для большинства типичных задач веб-разработки: от аутентификации. . .	Непрерывное развертывание в Java с Kubernetes Javaican 13.03.2025 Чем так привлекателен Kubernetes для развертывания Java-приложений? Этот оркестратор контейнеров позволяет автоматизировать развертывание, масштабирование и управление контейнеризированными. . .

@DrOffset 19410 / 10029 / 2443 Регистрация: 30.01.2014 Сообщений: 17,682
	12.01.2020, 19:54	21
	Сообщение от squareroot Я не против его заново присоединить, на этопа его уничтожения, только как ? Никак. Вы уже сказали через detach, что вас НЕ интересует дальнейшее управление потоком. Но потом вдруг выясняется, что все-таки оно вас интересует. Не находите здесь логического противоречия? Вы можете обосновать зачем понадобилось его отсоединять? 1

@squareroot 13 / 13 / 1 Регистрация: 19.10.2019 Сообщений: 607
	12.01.2020, 19:56 [ТС]	22
	Сообщение от DrOffset Никак. Вы уже сказали через detach, что вас НЕ интересует дальнейшее управление потоком. Но потом вдруг выясняется, что все-таки оно вас интересует. Не находите здесь логического противоречия? Вы можете обосновать зачем понадобилось его отсоединять? Мне нужно чтобы поток выполнялся не квазипараллельно, а параллельно основному потоку. Но на этапе его уничтожения, я хочу вернуть контроль. 0

@DrOffset 19410 / 10029 / 2443 Регистрация: 30.01.2014 Сообщений: 17,682
	12.01.2020, 20:11	23
	Сообщение от 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. 0

@squareroot 13 / 13 / 1 Регистрация: 19.10.2019 Сообщений: 607
	12.01.2020, 20:14 [ТС]	24
	Сообщение от DrOffset Оно и так будет параллельно работать. Откуда вы это взяли? Понял. Вот только ваш пример некроссплатформенный в части pthread_testcancel(); pthread_cancel в винде я могу заменить TerminateThread(GetThreadID(), 0); И тогда как быть pthread_testcancel(); ? Просто не использовать его в винде ? 0

@DrOffset 19410 / 10029 / 2443 Регистрация: 30.01.2014 Сообщений: 17,682
	12.01.2020, 20:36	25
	Сообщение от 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 . 0

@DrOffset 19410 / 10029 / 2443 Регистрация: 30.01.2014 Сообщений: 17,682
	12.01.2020, 21:49	27
	Сообщение от squareroot Я сделал так: Зачем? Вы прочитайте еще раз, что я вам написал. 0

@squareroot 13 / 13 / 1 Регистрация: 19.10.2019 Сообщений: 607
	12.01.2020, 21:53 [ТС]	28
	Сообщение от DrOffset Зачем? Вы прочитайте еще раз, что я вам написал. Затем что вариант с canselation point не особо нравится. В процедуре потока хочется обойтись без #ifdef винда ... #else линукс ... #endif Все эти примочки лучше в деструктор. 0

@DrOffset 19410 / 10029 / 2443 Регистрация: 30.01.2014 Сообщений: 17,682
	12.01.2020, 22:11	29
	Сообщение от 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. (функция нужна, чтобы оставить вашу основную процедуру потока без платфомозависимых вызовов). Использования функций жесткого завершения может привести к потере ресурсов или оставления ресурсов (например мьютексов) в некорректном состоянии. Нужно стараться избегать их всеми средствами. 1

@squareroot 13 / 13 / 1 Регистрация: 19.10.2019 Сообщений: 607
	12.01.2020, 22:22 [ТС]	30
	Сообщение от 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 минут Когда поток не хочет завершаться по хорошему, на потерю ресурсов при принудительном завершении можно не бращать внимание. 0

@DrOffset 19410 / 10029 / 2443 Регистрация: 30.01.2014 Сообщений: 17,682
	12.01.2020, 22:39	31
	Сообщение от squareroot на потерю ресурсов при принудительном завершении можно не бращать внимание. Тогда и на корректную работу приложения тоже можно не обращать внимания после этого. Если вас это устраивает - пожалуйста. Сообщение от squareroot Но деструктор должен уметь грохать поток, когда он не хочет завершаться по хорошему. Вот именно, когда. А вы по умолчанию пытаетесь впихнуть самый жесткий метод, о чем я вас и предупредил. В остальном, я вам дал достаточно вариантов. 0

@squareroot 13 / 13 / 1 Регистрация: 19.10.2019 Сообщений: 607
	12.01.2020, 22:43 [ТС]	32
	Сообщение от DrOffset Тогда и на корректную работу приложения тоже можно не обращать внимания после этого. Если вас это устраивает - пожалуйста. Вот именно, когда. А вы по умолчанию пытаетесь впихнуть самый жесткий метод, о чем я вас и предупредил. В остальном, я вам дал достаточно вариантов. Дак я уже три раза сказал, что код обстрагирован от реальной задачи. Тут просто прорабатываю самый жёский вариант, но в реальном коде конечно сначало будет попытка "договарится по хорошему" Вариантов недостаточно, потомучто поток может зависнуть в месте которое не имеет отношение к cancelation point. 0

@DrOffset 19410 / 10029 / 2443 Регистрация: 30.01.2014 Сообщений: 17,682
	12.01.2020, 22:46	33
	Вообще потоки, когда вероятной ситуацией является зависание, обычно не используют. Потому что их принудительное завершение всегда чревато потерей стабильности. Т.е. после такого завершения потока, разделяемые ресурсы уже будет невозможно привести к корректному состоянию, как, впрочем, и гарантированно узнать, что они в нем находятся. Единственное что можно сделать - это завершить весь процесс и перезапуститься. Поэтому в подобных системах, когда зависание - частая ситуация, применяют процессы, и управляют ими через какой-либо вариант IPC. Пример такой системы - браузер, где каждая вкладка - отдельный процесс, именно из-за угрозы зависания. Добавлено через 41 секунду Сообщение от squareroot Вариантов недостаточно, потомучто поток может зависнуть в месте которое не имеет отношение к cancelation point. Вариантов достаточно. Пункт 4) как раз об этом. 0

@squareroot 13 / 13 / 1 Регистрация: 19.10.2019 Сообщений: 607
	12.01.2020, 22:51 [ТС]	34
	Сообщение от DrOffset Вообще потоки, когда вероятной ситуацией является зависание, обычно не используют. Потому что их принудительное завершение всегда чревато потерей стабильности. Т.е. после такого завершения потока, разделяемые ресурсы ужебудет невозможно привести к корректному состоянию, как, впрочем, и гарантированно узнать, что они в нем находятся. Единственное что можно сделать - это завершить весь процесс и перезапуститься. Поэтому в подобных системах, когда зависание - частая ситуация, применяют процессы, и управляют ими через какой-либо вариант IPC. Пример такой системы - браузер, где каждая вкладка - отдельный процесс, именно из-за угрозы зависания. Добавлено через 41 секунду Вариантов достаточно. Пункт 4) как раз об этом. В ваших словах много правды, но я стремлюсь сделать обёртку которая будет убивать поток всегда, при любых обстоятельствах. 4й пункт не годиться потомучто неизвестно где поток зависнет. Я рассматриваю обёртку над std::thread как свой маленький sdk, поэтому мне надо чтоб он был универсален и надёжен. 0

@DrOffset 19410 / 10029 / 2443 Регистрация: 30.01.2014 Сообщений: 17,682
	12.01.2020, 22:58	35
	Сообщение от squareroot 4й пункт не годиться потомучто неизвестно где поток зависнет. Ну и что? Вы включаете асинхронное прерывание в самом начале и дальше уже без разницы где он завис. 0

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