[fpc-devel] weak referencing (was Suggestion:.....)

[Sven Barth]

Am 22.09.2014 16:45 schrieb "Peter Popov" <ppopov at hotmail.com>:
>
> How will referenced objects behave when referenced by a threadvar. This
is an exceptional situation for both dynamic arrays and ansi strings.

There is no need for special handling, afterall a threadvar is (roughly) as
if you had defined a variable locally to your thread's procedure.
If you have e.g. two threads and a threadvar of a reference counted class
type then thew are basically two possibilities:
- you assign two different instances of that variable's class type (or one
of its child classes) to each threadvar "instance"; in that case both class
instances will have refcount one (if they aren't referenced anywhere else)
and each will be freed when its corresponding thread goes out of scope (if
threadvar finalization works correctly, bit that is a different topic)
- you assign the same class instance to both threadvar "instances"; then
the reference count will be 2 (if it isn't referenced anywhere else) and
the instance will be freed once the last of the two threads finalizes its
threadvars.

It's the same for interfaces, strings and arrays. The special handling is
only for threadvars in general, but not for the types it holds.

>
> Another comment: If referenced objects all derive from a single base,
then, the user cannot possibly have another hierarchy, which uses ref.
objects. As I mentioned earlier, I do this explicitly for an object well
down my hierarchy. So, it seems to me you still need something like:
>
> -- code --
>
>
> TRefObject = referenced class(TWhateverBase)
> end;
>
>
> -- end of code --

That's what I suggested in my RFC: have a possibility to declare a class
somewhere down the hierarchy as reference counted and provide - using this
possibility - a direct reference counted descendant of TObject inside the
System unit for convenience reasons.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140922/b075256e/attachment.html>