Re: [bug #4189] broken bycopy in DO

[Richard Frith-Macdonald]

On Friday, July 4, 2003, at 02:48  pm, Alexander Malmberg wrote:

> Richard Frith-Macdonald wrote:
> [snip]
> > This *is* an issue preventing you from  using setProtocolForProxy: in
> > some
> > sotuations in code built with an olk compiler [snip]
>
> NSDistributedNotificationCenter is such a situation. I've attached a
> patch that works around it. Not pretty, but things seem to work now
> (better, at least; there are a couple of "Changed type signature"
> warnings, and a few slightly odd details).

Yes, for the moment I've just disabled the use of setProtocolForProxy:
where it might be a problem ... Probably we should use this sort of
dummy class solution though, I'm not sure how long we will want to
support older compilers, but if it's for a significant length of time I 
think
the workaround is worth putting in.

However, the bigger problem seems to be with applications crashing
with the change to use type info from the remote end of a connection.
This didn't happen at all with my own DO code, but seems to happen
a lot in other applications.
Basically, the problem seems to be this -

If the compiler can see a protocol declaration containing protocol
qualifiers (bycopy, byref, in, out, inout, oneway) it generates code
at the calling end to send a message using a typed selector
containing these qualifiers.  In other words, as long as there is a
visible protocol declaration, the local calling code will use it.  This
is why the old DO code works perfectly in normal circumstances.

With the change to use the type information form the remote end,
we depend on what the runtime at the remote end can tell us, and
the remote object will not have the protocol qualifier information
available to it unless the class was declared as conforming to the
protocol.

In a lot of places, people have written systems where the calling
code knows about a protocol (because it's visible to the compiler)
but on the server side the runtime doesn't know about the protocol
(because the class of the server object does not conform to it).

In an attempt to get the best of both worlds, I've tried to modify
the system so that, if the types signature supplied locally contains
any protocol qualifiers, we assume that it is the correct signature
and don't query the remote object ... not ideal, but should do for now.