On Wed, 19 Oct 2005 16:52:03, Chris Hanson <email@hidden> wrote:
> On Oct 18, 2005, at 7:27 AM, Eric Schlegel wrote:
>
>> Actually, it really has no meaning. It's text that is automatically
>> generated by the tool that generates the header files, but it
>> doesn't really make sense to speak of an event as being thread-safe
>> or thread-unsafe.
>
> Actually, it does.
>
> If an object is thread-safe, it is OK to access that object from
> multiple threads at once without locking. In other words, the object
> or the API used to access it performs its own locking as necessary to
> maintain the object's consistency.
>
> If an object is not thread-safe, it is not OK to access that object
> from multiple threads at once without locking. In fact, it may not
> be OK to access that object from any thread but the main thread,
> since the object may be accessed without locking internally to APIs
> whose locking behavior a third-party developer cannot control.
>
> There is a third state that's hard to name but easy to describe: An
> object may not be thread-safe, but may be safe to access from a
> single thread at once regardless of what that thread is when
> appropriate locking is used. This is the case if the object's
> lifecycle and use is controlled by whoever instantiated the object,
> or if there some other way to share a locking mechanism among all
> users of the object.
"Object"? The related concept in Carbon Events is event target and
being the "upper half" concept it is not thread safe. Carbon event
constants themselves can't be thread safe or not safe (they are
just integers). If you wish to treat them as "methods" you surely
can, but then, the only relevant APIs are PostEventToQueue and
SendEventToEventTarget; this is the "send" that can be treated
as "method invocation" (the "post" doesn't invoke anything itself)
and "send" it is not thread safe no matter what "object" you are
talking to and what event you are sending it (what method you call).
Dead end.
Now, if the rules are going to change and "send" is going to be
re-implemented to be thread safe (along with the whole "upper
half" stuff) - [I wish that was true, is it going to happen?] -
then indeed assigning thread safety category to particular
events would make sense (along with enforcing rules that you
can't install thread-unsafe handler on event documented as
thread safe, etc).
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
