[omniORB] Accessing methods after join?

[Bruce Visscher]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Johnson wrote:

> If I derive from omni_thread can I access my thread class's methods after a
> join has returned? Also, do I need to delete the object after a join?

omni_thread takes care of deallocating threads for you, so the answer to each of
these questions is no.  To see why it is good that omnithreads does this,
consider the case of the detached thread.  It would be inconvenient for the
thread author to try to handle deleting itself.  (See Marshal Cline's C++ FAQ on
deleting this.  IMHO, this is one of the best examples where "delete this" is
appropriate.  Fortunately, though, we don't have to do this ourselves.)

> 
> example:
> 
>   MyThread * thread = new MyThread; // starts undetached
>   thread->join( (void**)&rv );
>   std::cout << thread->getName() << " has finished. " << std::endl;  //
> don't think this will work
>   delete thread; // ??
> 
> In the examples directory the following example was given:
> 
> int main(int argc, char** argv)
> {
>     thread_with_data* t = new thread_with_data;
> 
>     cerr << "main: joining\n";
> 
>     int* rv;
>     t->join((void**)&rv);
> 
>     cerr << "main: joined - got return value " << *rv << endl;
> 
>     delete rv;
> 
>     return 0;
> }
> 
> But I'm confused as to why they bothered deleting 'rv'

Without looking at the example, I would guess that the reason the int is
allocated on the heap via new is because there really isn't a better way to
handle passing data back to the thread that is performing the join.  It would be
an error to return a pointer to a local variable that is about to go out of
scope.  You could use a static variable, but that raises synchronization issues.

Alternatively, the join member could have been designed to return a value, but
then we'd be limited to a single type (e.g., int).

Of course, you don't *have* to pass anything back from join (I usually don't). 
If you don't need to then just pass a `0' to join and return `0' from your
thread function.

> and not 't' too?

Again, it is both unnecessary and incorrect to delete a pointer to an
omni_thread.

HTH,

Bruce Visscher
-- 

Bruce Visscher                                        visschb@rjrt.com

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"

CONFIDENTIALITY NOTE:  This e-mail message, including any attachment(s), contains information that may be confidential, protected by the attorney-client or other legal privileges, and/or proprietary non-public information.  If you are not an intended recipient of this message or an authorized assistant to an intended recipient, please notify the sender by replying to this message and then delete it from your system.  Use, dissemination, distribution, or reproduction of this message and/or any of its attachments (if any) by unintended recipients is not authorized and may be unlawful.


--------------InterScan_NT_MIME_Boundary--