not sure how to get quick termination of blocking threads

[mmarchywka]

[mmarchywka]

I wrote a test program using libetpan and tried to infer the API from the examples and source code. It generally seems to work well on the simple IMAP downloads I have tried. However, I'm not sure how to quickly kill the threads. If I open say 50 sessions to an IMAP server, some are rejected and that works ok ( although I have not checked for memory leaks etc). However, when I try to exit the code there always seems to be one thread hanging. The one stack trace I obtained looks like this and curious if you have some API call or way to terminate the stuck select, #0 0x00007ffff6e385d3 in select () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff6e385d3 in select () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff78edae0 in wait_read (s=0x7fff340028d0, s=0x7fff340028d0) at mailstream_ssl.c:873 #2 mailstream_low_ssl_read (s=0x7fff340028d0, buf=0x7fff34011520, count=8192) at mailstream_ssl.c:915 #3 0x00007ffff78eb723 in mailstream_low_read (s=0x7fff340028d0, buf=0x7fff34011520, count=) at mailstream_low.c:232 #4 0x00007ffff78ecbf4 in mailstream_feed_read_buffer (s=s@entry=0x7fff34019650) at mailstream.c:304 #5 0x00007ffff78ead20 in mailstream_read_line_append (stream=stream@entry=0x7fff34019650, line=line@entry=0x7fff34002910) at mailstream_helper.c:101 #6 0x00007ffff78ff6d8 in mailimap_cont_req_or_resp_data_parse_progress (fd=fd@entry=0x7fff34019650, buffer=buffer@entry=0x7fff34002910, parser_ctx=parser_ctx@entry=0x7ffff0085340, indx=indx@entry=0x7ffff5b180e8, result=result@entry=0x7ffff5b180f0, progr_rate=progr_rate@entry=0, progr_fun=0x0, body_progr_fun=0x0, items_progr_fun=0x0, context=0x0, msg_att_handler=0x0, msg_att_context=0x0) at mailimap_parser.c:8972 #7 0x00007ffff78ff844 in mailimap_struct_multiple_parse_progress (parser=0x7ffff78ff4f0 <mailimap_cont_req_or_resp_data_parse_progress>, destructor=, msg_att_context=0x0, msg_att_handler=0x0, context=0x0, items_progr_fun=0x0, body_progr_fun=0x0, progr_fun=0x0, progr_rate=0, result=, indx=, parser_ctx=0x7ffff0085340, buffer=0x7fff34002910, fd=0x7fff34019650) at mailimap_parser.c:935 #8 mailimap_response_parse_progress (fd=0x7fff34019650, buffer=0x7fff34002910, parser_ctx=parser_ctx@entry=0x7ffff0085340, indx=indx@entry=0x7ffff5b18190, result=result@entry=0x7ffff5b18198, progr_rate=0, progr_fun=0x0, body_progr_fun=0x0, items_progr_fun=0x0, context=0x0, msg_att_handler=0x0, msg_att_context=0x0) at mailimap_parser.c:9044 #9 0x00007ffff78ffca7 in mailimap_response_parse (fd=, buffer=, parser_ctx=parser_ctx@entry=0x7ffff0085340, indx=indx@entry=0x7ffff5b18190, result=result@entry=0x7ffff5b18198, progr_rate=, progr_fun=0x0) at mailimap_parser.c:9123 #10 0x00007ffff78f526c in mailimap_parse_response (session=session@entry=0x7fff34019350, result=result@entry=0x7ffff5b18200) at mailimap.c:2509 #11 0x00007ffff78f58c0 in mailimap_logout (session=0x7fff34019350) at mailimap.c:751 #12 0x00007ffff7935a5e in imapdriver_logout (session=0x7fff34001000) at imapdriver.c:326 #13 0x00007ffff794eb92 in mailstorage_disconnect (storage=storage@entry=0x7fff340008c0) at mailstorage.c:333 #14 0x00007ffff794ebc0 in mailstorage_free (storage=0x7fff340008c0) at mailstorage.c:287

Thanks.

[dinhvh]

One workaround is to not call mailimap_logout() and just close the connection with mailimap_close().