Hi,
Anybody, could You help me, please !
Detached thread (for which was called pthread_detach or which was created with PTHREAD_CREATE_DETACHED mode):
which resources are allocated automatically as said in docs?
i.e. what about:
memory,
channels,
connections,
opened files,
mutexes,
etc ???
Thanks a lot,
Vasili
vasa <vv40in@mail.ru> wrote:
Detached thread (for which was called pthread_detach or which was created with PTHREAD_CREATE_DETACHED mode):
which resources are allocated automatically as said in docs?
i.e. what about:
memory,
channels,
connections,
opened files,
mutexes,
etc ???
I’m not sure what you’re asking, but when a thread is created a local stack is made.
So this would imply that memory is being used for the setup, but connections, channels
, open files, and mutexes???. A thread has process wide access - perhaps I’m not
understanding your question.
-Adam
Excuse me,
It was “misprint” 
It is
In pthread_detach docs in QNX 6.1 Library Reference wrote:
When a detached thread terminates, all system resources allocated to that thread are immediately reclaimed.
which resources are reclaimed automatically as said in docs?
–
Best regards,
Vasilii
Operating System for Tech Supp <os@qnx.com> ÓÏÏÂÝÉÌ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ:9o572r$qfr$2@nntp.qnx.com…
vasa <> vv40in@mail.ru> > wrote:
Detached thread (for which was called pthread_detach or which was created with PTHREAD_CREATE_DETACHED mode):
which resources are allocated automatically as said in docs?
i.e. what about:
memory,
channels,
connections,
opened files,
mutexes,
etc ???I’m not sure what you’re asking, but when a thread is created a local stack is made.
So this would imply that memory is being used for the setup, but connections, channels
, open files, and mutexes???. A thread has process wide access - perhaps I’m not
understanding your question.-Adam
“vasa” <vv40in@mail.ru> wrote in message news:9o5oat$cll$1@inn.qnx.com…
Excuse me,
It was “misprint” >It is
In pthread_detach docs in QNX 6.1 Library Reference wrote:
quote
When a detached thread terminates, all system resources allocated to that
thread are immediately reclaimed.
/quotewhich resources are reclaimed automatically as said in docs?
As the docs says: All
–
Best regards,
VasiliiOperating System for Tech Supp <> os@qnx.com> > ÓÏÏÂÝÉÌ × ÎÏ×ÏÓÔÑÈ
ÓÌÅÄÕÀÝÅÅ:9o572r$qfr$> 2@nntp.qnx.com> …
vasa <> vv40in@mail.ru> > wrote:Detached thread (for which was called pthread_detach or which was
created with PTHREAD_CREATE_DETACHED mode):
which resources are allocated automatically as said in docs?
i.e. what about:
memory,
channels,
connections,
opened files,
mutexes,
etc ???I’m not sure what you’re asking, but when a thread is created a local
stack is made.
So this would imply that memory is being used for the setup, but
connections, channels
, open files, and mutexes???. A thread has process wide access -
perhaps I’m not
understanding your question.-Adam
Excuse me,
It was “misprint” >It is
In pthread_detach docs in QNX 6.1 Library Reference wrote:
quote
When a detached thread terminates, all system resources allocated to that
thread are immediately reclaimed.
/quotewhich resources are reclaimed automatically as said in docs?
As the docs says: All
It is doubtful.
I see that sockets does not close, memory did not free…
or may be question is not understandable ?
once more:
Q: which resources are DEallocated automatically as said in docs?
Vasilii
Detached thread (for which was called pthread_detach or which was
created with PTHREAD_CREATE_DETACHED mode):
which resources are deallocated automatically as said in docs?
i.e. what about:
memory,
channels,
connections,
opened files,
mutexes,
etc ???
“vasa” <vv40in@mail.ru> wrote in message news:9o7t3p$mna$1@inn.qnx.com…
Excuse me,
It was “misprint” >It is
In pthread_detach docs in QNX 6.1 Library Reference wrote:
quote
When a detached thread terminates, all system resources allocated to
that
thread are immediately reclaimed.
/quotewhich resources are reclaimed automatically as said in docs?
As the docs says: All
It is doubtful.
I see that sockets does not close, memory did not free…or may be question is not understandable ?
It was very clear. It appears I was dead wrong. I made
an fault assumption. After a quick test, I was surprise to
see memory is not freed. Documentation to pthread_exit
says process resources such as mutext and file descriptors
are not returned to the OS. I couldn’t find anywhere
in the doc what qualify as a process resources versus
thread resources.
sorry for the confusion.
once more:
Q: which resources are DEallocated automatically as said in docs?Vasilii
Detached thread (for which was called pthread_detach or which was
created with PTHREAD_CREATE_DETACHED mode):
which resources are deallocated automatically as said in docs?
i.e. what about:
memory,
channels,
connections,
opened files,
mutexes,
etc ???
\
Mario Charest <mcharest@clipzinformatic.com> wrote:
It was very clear. It appears I was dead wrong. I made
an fault assumption. After a quick test, I was surprise to
see memory is not freed. Documentation to pthread_exit
says process resources such as mutext and file descriptors
are not returned to the OS. I couldn’t find anywhere
in the doc what qualify as a process resources versus
thread resources.
When a thread terminates, the clean up handlers are called. Then
any thread specific data, with non-NULL values, have their deconstructors
functions called for those keys. Then it releases any resources left
such as storage for the thread’s return value, the stack, memory
used to store thread register state etc.
Things like file descriptors are process resources, as you
wouldn’t get a new set of file descriptors for each thread
you could spawn. Mutexes generally fall outside of a thread
specific scope (except maybe the main()). If you allocated
a mutex inside a thread (ie. off the stack, not malloc’d),
then it too would be “cleaned” up but it’s a bad design
to have a thread lock on a mutex sitting on another threads
stack.
Basicly aside from thread specific information, cleanup handling
stack, thread stack, return values and thread state info, I think
the rest could be considered a process resource.
-Adam
amallory@qnx.com
Operating System for Tech Supp <os@qnx.com> wrote:
When a thread terminates, the clean up handlers are called. Then
any thread specific data, with non-NULL values, have their deconstructors
functions called for those keys. Then it releases any resources left
such as storage for the thread’s return value, the stack, memory
used to store thread register state etc.Things like file descriptors are process resources, as you
wouldn’t get a new set of file descriptors for each thread
you could spawn. Mutexes generally fall outside of a thread
specific scope (except maybe the main()). If you allocated
a mutex inside a thread (ie. off the stack, not malloc’d),
then it too would be “cleaned” up but it’s a bad design
to have a thread lock on a mutex sitting on another threads
stack.
An interrupt handler may also be associated with a thread, and
cleaned up on its death.
Basicly aside from thread specific information, cleanup handling
stack, thread stack, return values and thread state info, I think
the rest could be considered a process resource.
There are two more levels of cleanup.
Most remaining resources are cleaned up when the process that owns
those resources exits – including memory, coids & fds, channels,
etc. Synchronisation objects (e.g. mutexes, condvars, semaphores,
etc.) are cleaned up when the memory they are in is released – usually
this means they are cleaned up when the process exits.
The exception is objects that have a name in the pathname space associated
with them, or specifically, ones that have a name created by an *open()
function with the O_CREAT flag, e.g.: sem_open(), shm_open(), open(),
mq_open(). These objects are cleaned up when the name has been unlinked
and all references to the object have been closed (for fds) or otherwise
ended (e.g. un-mapped for mmap() references to an object). (A name in
the name space created by, say, resmgr_attach(), will be cleaned up
if the process exits – it is a name, but not of the type above.) A
side-effect of this, of course, is that semaphores in a shared memory will
not be cleaned up when the process that created them exits, but instead
will endure as long as the shared memory area exists, as one would hope.
QNX Training Services
dagibbs@qnx.com