Re: problems with forward invocation (gcc bug?)

[Wim Oudshoorn]

>
> > Yes.  This is actually pretty critical since Apple documentation
> > recommends
> > using distributed objects to provide thread safety, and this problem
> > means
> > that DO in GNUstep is currently not thread-safe (though the fact that it
> > has been heavily exercised without problems suggests that the actual
> > chances
> > of hitting this problem are very small).
>
> Well, as long as you only use return types:
> void, char, int, long and pointer
> I think you are safe.
>
> So most probably there are not a lot of programs
> out there that use forwarding with other return types
> and are heavily multithreaded at the same time.
>
> > Yes, but until/unless the objc runtime is modified to provide it,
> > just using id will be a pretty good bet.
> > If/when that does become available, I think the order should be -
> >
> > - type info encoded in the selector.
> > - type info by asking the receiver for a signature.
> > - type info from an equivalent selector.
> > - use id.
> >
>
> Yes.
>
> Last night I have been playing a little with type detection
> for a selector.  But getting to the type information
> is a little hampered by the public API of the GNU objc
> runtime.  It is possible, but direct access to the
> internal data structures would be much easier.
>
> So how tightly integrated is the GSFCallBack...
> stuff with the GNU objc runtime anyway?
> I thought it was also supposed to run on different
> runtimes, like NeXT or darwin.  Doesn't calling
> functions like sel_get_types () break that?
>

I have a modified version of GSFFCallInvocation
that determines the return type in gs_objc_msg...
But it needs cleaning up.  Question to the GNUstep maintainers:

a.  Is it OK to assume that, for the return type
        all pointer types are equivalent?
        The ffcall library does, and it will reduce
        the coding effort involved.  (And I can not
        imagine a platform where it is different anyway)
        
        And in the same spirit: use non public
        macros from the ffcall packages?
        (I think the current implementation already
        does and it might be very hard/impossible
        without)

b.  Is it OK to access directly the data structures
        in libobjc (the method list etc.)



Wim Oudshoorn.