Re: PATCH: Add objc_thread_add and objc_thread_remove to libobjc

[Nicola Pero <n dot pero at mi dot flashnet dot it>]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

    Stan> Nicola Pero wrote:
    >> Hi
    >> 
    >> here are two functions which can be used to have Objective-C
    >> threads cooperate with threads started from alien environments
    >> (eg, to allow Objective-C calls being made from arbitrary Java
    >> threads without causing thread problems to the objc runtime).
    >> This functionality is not covered by existing libobjc thread
    >> code as all code there requires you to start and stop your
    >> threads using libobjc - you can't access the runtime from a
    >> thread started by java for example.  These two functions fix
    >> this problem.

    Stan> At first blush, this all seems reasonable, but I'm curious;
    Stan> is there no documentation for libobjc?  The one .texi file
    Stan> doesn't seem to mention most of the functions exported from
    Stan> libobjc.  Also, how hard would it be to set up a test that
    Stan> didn't involve most of GNUStep?

Well - testing interfacing the objc thread system with alien threads
is going to be difficult - in that you have to write a different test
for each different thread system, because in each thread system you
create threads in a different way, and you can't use the libobjc
wrappers otherwise you are not testing it.  For this reason, I don't
think it is reasonable to attempt writing a test for that for the
testsuite.

I had been thinking perhaps I could write some example code using
pthreads that would convince you that the stuff works - but I had no
time so far to do it - and I'm not really planning for it as it looks 
like a bit unnecessary/useless.

So, I think a plain explanation will do and cost me much less time.
Probably it won't tell you anything more than what you have already
figured out yourself when looking at the patches. :-)

The objc runtime to work internally with threads does the following
things:

1.if it is running multithreaded, it protects access to all resources
which might cause conflicts with locking.  Once it gets in
multithreading mode, it never gets out of it.

2. there is a counter of the number of threads running, which gets
increased or decreased when threads start or stop; this is only used -
as far as I remember - in a point to decide how to free some garbage
memory - I don't know much of that code.

So, in order to call the objc runtime from a new alien thread, you
just need to make sure you put the objc runtime in multithreading
mode, and that you manage the counter.  That is what the little
functions do.

JIGS runs multithreading <and that's not obvious as it took a lot of
effort to make it work> so the two functions can't contain something
obviously wrong, otherwise that would stop JIGS from working.

+

I've seen that you have committed the functions - thanks - sorry for
the late reply as I had left the mail half-finished waiting for when I
would have had the time to write a test, but I never had :-) and now
it's time I say something.  Thanks again.