On 01/09/14 13:16, Patrik Flykt wrote:
On Sat, 2014-08-30 at 15:15 +0300, Slava Monich wrote:
This is for pacrunner.
More motivation in here why this patch is good, please.
Cheers,
Patrik
A thread may either be/joinable/ or/detached/. If a thread is
joinable, then another thread can callpthread_join(3)
<http://man7.org/linux/man-pages/man3/pthread_join.3.html> 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. When a detached thread
terminates, its resources are automatically released back to the
system: it is not possible to join with the thread in order to obtain
its exit status. Making a thread detached is useful for some types
of daemon threads whose exit status the application does not need to
care about. By default, a new thread is created in a joinable state,
unless/attr/ was set to create the thread in a detached state (using
pthread_attr_setdetachstate(3)
<http://man7.org/linux/man-pages/man3/pthread_attr_setdetachstate.3.html>).
And here is a piece of evidence from valgrind:
==14392== HEAP SUMMARY:
==14392== in use at exit: 99,659 bytes in 3,563 blocks
==14392== total heap usage: 11,478 allocs, 7,915 frees, 8,096,821 bytes
allocated
==14392==
==14392== 31,104 bytes in 216 blocks are possibly lost in loss record
709 of 709
==14392== at 0x483643C: calloc (vg_replace_malloc.c:593)
==14392== by 0x4013B37: _dl_allocate_tls (dl-tls.c:297)
==14392== by 0x49C0947: pthread_create@@GLIBC_2.4 (allocatestack.c:571)
==14392== by 0x1418F: find_proxy_for_url (client.c:97)
==14392== by 0x107CB: process_message (object.c:259)
==14392== by 0x49F58A3: _dbus_object_tree_dispatch_and_unlock
(dbus-object-tree.c:862)
==14392== by 0x49E5F9B: dbus_connection_dispatch (dbus-connection.c:4672)
==14392== by 0xD66B: message_dispatch (mainloop.c:72)
==14392== by 0x48F7A8B: g_idle_dispatch (gmain.c:5251)
==14392== by 0x48FBB1F: g_main_context_dispatch (gmain.c:3066)
==14392== by 0x48FBE23: g_main_context_iterate.part.19 (gmain.c:3713)
==14392== by 0x48FC48B: g_main_loop_run (gmain.c:3906)
==14392==
==14392== LEAK SUMMARY:
==14392== definitely lost: 0 bytes in 0 blocks
==14392== indirectly lost: 0 bytes in 0 blocks
==14392== possibly lost: 31,104 bytes in 216 blocks
==14392== still reachable: 68,555 bytes in 3,347 blocks
==14392== suppressed: 0 bytes in 0 blocks
And I'm pretty sure it was leaking some kernel resources as well.
Regards,
-Slava
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
