Re: Distributed Objects help - a fun hack
Re: Distributed Objects help - a fun hack
- Subject: Re: Distributed Objects help - a fun hack
- From: Peter Ammon <email@hidden>
- Date: Tue, 4 Sep 2001 17:44:07 -0400
On Tuesday, September 4, 2001, at 01:33 PM, Miguel Morales wrote:
Dear Peter,
DO works VERY hard to keep everything thread safe (even object double
pointers get dereferenced). This is the reason for the
NSDistantObjects you are getting. Now there are situations where you
can guarantee that an object will not be accessed by multiple threads,
and you don't want the overhead of using the 'bycopy' keyword. The
hack I have found to this is the following set of calls, making use of
casting so that the DO system does not know an object is involved. I
have no idea if this will survive various upgrades, but it works on
both OS X 10.0.4 and GNUStep under Linux without any problems (just a
compiler warning). If anyone out there knows of a better method, I'd
love to hear it.
Hi Miguel, and thanks for your great response. You're right, DO does
work very hard: it ferreted out my object pointers even when I wrapped
them in a struct!
Casting the pointer to a long is a clever trick, and one that I hadn't
thought of.
A solution that worked for me was to record the object pointer in
instance variables (declared volatile!) of the object I'd send the
message to; the method performed in the main thread could just grab the
"parameters" from its instance variables. I imagine that the
synchronization required to prevent overwriting still-needed parameters
made that inefficient.
If I may offer a suggestion: currently, sending a void* parameter
between threads results in a runtime error because the runtime doesn't
know how to encode what the void* points to. Instead of that, why not
make the runtime pass the void* pointer like it passes primitives? That
would obviate the need for implementation-defined hacks like passing
pointers in ints.
Thanks once more!
[snip]
-Peter