Am 21.09.2014 06:11 schrieb Boian Mitov mi...@mitov.com:
Unless you implement something like the semi-deterministic GC that I
proposed few years ago, weak pointers are the only solution for avoiding
circular reference deadlock in ARC as far as I know. They are simply
necessary evil, and a small
Am 21.09.2014 um 07:22 schrieb Hans-Peter Diettrich:
Boian Mitov schrieb:
That is easy. it gets incremented when it gets assigned. The running threads
have no way of
accessing it if there is no reference (assignment) already in place.
The problem arises when an object is destroyed, or even
I was looking at the following example in DXE7
http://delphiaball.co.uk/
procedure TFormThreading.Button1Click(Sender: TObject); var aTask: ITask; begin
// not a thread safe snippet aTask := TTask.Create (procedure () begin sleep
(3000); // 3 seconds ShowMessage ('Hello'); end); aTask.Start;
Il 21/09/2014 05:51, Hans-Peter Diettrich ha scritto:
Giuliano Colla schrieb:
I might, for example, tell you that my company has been successfully
implementing since more than 30 years a class of applications for the
control of industrial processes, with hundreds of threads running
On 21/09/14 08:10, Samuel Herzog wrote:
But it's not accepted.
*procedure* TFormThreading.Button1Click(Sender: TObject);
*var*
aTask: ITask;
**procedure* *MyTask*;
*begin*
*sleep (3000); // 3 seconds*
*ShowMessage ('Hello');*
* end*
begin*
// not a thread
On 21.09.2014 12:13, Jonas Maebe wrote:
On 21/09/14 08:10, Samuel Herzog wrote:
But it's not accepted.
*procedure* TFormThreading.Button1Click(Sender: TObject);
*var*
aTask: ITask;
**procedure* *MyTask*;
*begin*
*sleep (3000); // 3 seconds*
*ShowMessage ('Hello');*
On 21.09.2014 05:34, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
Am 20.09.2014 20:34 schrieb Giuliano Colla
A general mechanism to be reliable should take into account all
possibilities. If it does, it will block threads even when
unnecessary. If it doesn't, it will be unsafe.
That
In our previous episode, Hans-Peter Diettrich said:
IMO Weak references should be reserved for users who accept possible
consequential problems, but should never be used in standard libraries.
At least I'd suggest to make weak references subject to an compiler
switch, so that every user
On 20.09.2014 13:42, Sven Barth wrote:
On 20.09.2014 13:11, Peter Popov wrote:
Please do not reference count TObject. This is a uniquely bad and
unnecessary idea. I will switch to ANSI C if you guys do it
Please enlighten me why you think it is bad. Give reasons and don't be
like a farmer
In our previous episode, Sven Barth said:
(as sb purely interested from an academic viewpoint, I have no real need for
this)
- a reference counted class (and its child classes) would include a
reference count field that the compiler knows how to access (for
automatic reference counting) and
On 21.09.2014 13:20, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
(as sb purely interested from an academic viewpoint, I have no real need for
this)
Understood.
- a reference counted class (and its child classes) would include a
reference count field that the compiler
On 21.09.2014 14:15, Chriss Kalogeropoulos wrote:
Hi Sven,
This design means that old classes need to be subclassed in order to
enable this feature, correct?
Would it be possible instead of declaring this on the class definition,
to declare it on the actual variable? Something like
var
In our previous episode, Sven Barth said:
No, not multiple roots. If a class is declared as refcounted (and it's
parent class is not) then a hidden field is inserted into its list of
fields, just as a normal one would, only that it isn't accesible using
the .-operator (because it won't have
On 21.09.2014 15:09, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
No, not multiple roots. If a class is declared as refcounted (and it's
parent class is not) then a hidden field is inserted into its list of
fields, just as a normal one would, only that it isn't accesible
On Sun, Sep 21, 2014 at 9:15 AM, Chriss Kalogeropoulos
iz.iznog...@gmail.com wrote:
Hi Sven,
This design means that old classes need to be subclassed in order to
enable this feature, correct?
Would it be possible instead of declaring this on the class definition, to
declare it on the
Hans,
There is no such problem. We run many hundreds of threads sharing and
passing interface data for 11 years already, and in the last 2 years doing
it with Anonymous methods as well.
I can assure you it works 100%. There is no problem.
And since we are component vendor, it also works for
The biggest problem is when to initiate the detection and still maintain some
form of determinism. That was the algorithm I proposed a while back, but it was
not without a drawbacks. It would have affected performance.
There is not really a silver bullet for this as far as I know.
With best
Hi Sam,
You can watch my CodeRage session last year explaining the huge advantages of
the first syntax.
That being said, I consider it a design bug that local functions can’t be
passed as anonymous methods in Delphi. There is no reason for that not to be
done, except that they did not
I used to think the same way, until I actually started to use anonymous
methods, and I realized what a full I used to be.
The simplest difference is that you can return anonymous method as a result
of your function and it will preserve all the captured context.
Local methods can't do that.
Absolutely! Interfaces have been used in threading for decades already in
may languages. I have also never heard of anyone having issues with them.
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
Every memory management system has a manual part, even the M$/Java GC has
element of it (the dreadful Disposable pattern to name one).
There is a huge difference however. ARC requires in general less coding for
the same result.
Less code in general is cheaper to develop, debug, read and
In general I would prefer to see this implemented with attributes rather
than with new keywords. For god shake, we already have more keywords in this
language than it is healthy. We should be extremely cautions when adding new
ones.
That is one of the beauty of the attributes. They can
[Jonas: anonymous methods and local functions could use the same syntax]
On 21/09/14 18:43, Boian Mitov wrote:
I used to think the same way, until I actually started to use anonymous
methods, and I realized what a full I used to be.
The simplest difference is that you can return anonymous
Hi Jonas,
I actually agree that it is a nice feature, and I want to have it both in
Delphi and FPC :-) .
I prefer the anonymous method syntax as it means less typing, and typing is
expensive, however there are cases when I really would love to capture local
function. I had few of them
I just want to remind you people (whoever is working on it) that ARC is already implemented in FPC for interface types and I am personally satisfited with the way it works now for interface variables, and only wish that I could enable this feature for class instance variables. Can't someone just,
1. I mostly care for performance, so I will start here: They add overheads
which in certain situations can be very bad. These can come in many
shapes, including additional memory for the reference counter, creating
cache incoherence when doing local object assignments (which would cause
some
I just want to remind you people (whoever is working on it) that
ARC is already implemented in FPC for interface types and I am personally
satisfited with the way /it works now/ for interface variables, and
only wish that I could enable this feature for class instance variables.
Can't
So why are you not programming in Assembler?
The arguments you provide are the same that ware provided against higher
level languages, adding OOP, adding anonymous methods, just to name few.
I spent 2 years streamlining all of our code - 4 mln. lines of code to use
the latest language features,
Ahh... the schizophrenic nature of Object Pascal :-D, I never understood why
interface and class should be different at first place, considering that
interface is practically nothing more than pure abstract class with ref.
counting. Why the separated syntax etc. is beyond me... Surely helps
I strongly disagree... I think there is a great value in a reference
counted object, especially if we can enable/disable that with virtual
method or even better attribute ;-) .
Then you will have it any way you want :-) .
Hi Boian
I do not mind if this is done on a derived object. As
Interfaces, among other things, are a way to bring in some features from
multiple inheritance. I think the term is one-sided multiple inheritance.
If multiple inheritance is good or bad is a separate topic. With time, one
begins to doubt the utility of classes in the first place and starts
Sven,
based on your comments a bizarre thought came to me. Currently, class
instances are pointers. What you propose will somehow create a special
pointer type (referenced class).
Should this be done, I have a request: create a 4 byte compressed class
reference which expands into an 8 byte
In our previous episode, Boian Mitov said:
Every memory management system has a manual part, even the M$/Java GC has
element of it (the dreadful Disposable pattern to name one).
There is a huge difference however. ARC requires in general less coding for
the same result.
Less code in general
This is not true. Ref pointer is exactly the same size as non ref pointer.
the counter is in the instance not in the pointer to the instance ;-) .
You can study the interface implementations or the String implementations
they are done the same way.
With best regards,
Boian Mitov
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
IMO Weak references should be reserved for users who accept possible
consequential problems, but should never be used in standard libraries.
At least I'd suggest to make weak references subject to an compiler
Sven Barth schrieb:
On 20.09.2014 13:42, Sven Barth wrote:
On 20.09.2014 13:11, Peter Popov wrote:
- to remedy this TObject is extended with non-virtual methods that allow
manual reference counting and would rely on the RTTI data I mentioned
(let's call the methods AddRef, Release,
Florian Klämpfl schrieb:
Am 21.09.2014 um 07:22 schrieb Hans-Peter Diettrich:
Boian Mitov schrieb:
That is easy. it gets incremented when it gets assigned. The running threads
have no way of
accessing it if there is no reference (assignment) already in place.
The problem arises when an
In general you can have good and bad designs with and without ARC/weak
pointers/ or sweep GC.
From all of the above, and I have done them all for years, the ARC is the
easiest to manage, and the one with the least side effects. What you was
does not differ from the issues of lost pointers in
Yes!
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
---
Is it really sufficient to protect refcounter changes by Interlocked
Inc/Dec, to prevent race conditions while
That is not what I suggested. The idea is to compact an 8 byte pointer to
a 4 byte one. Basically,
save memory. This would limit the accessible memory tough. Probably for a
different thread.
HOWEVER: here is another one idea. Current memory buses are 48 bit wide,
so basically a pointer can
Am 20.09.2014 22:54, schrieb Gennady Agranov:
If you want to do ARC for objects - just remove this limitation and
allow compiler to generate reference counting code not just for for
interfaces but for classes that implement interface - AFAIK any
interface in FPC/Delphi extends IUnknown and has
22.09.2014 0:28, Peter Popov:
[...]
So, for classes which are reference counted, store the reference count @
the highest two bytes of the class instance (which in practice is a
pointer to the VMT). This would let you ref-count up to 2^16. You need to
mask it out from the rest of the pointer when
We probably should if possible keep pointers just pointers (Ref counted
pointer is same a non ref counted as we discussed so same size).
Otherwise we may end up adding bits for the Moon Phases or something in it.
Even if we add ARC we should do it as simple as possible and without
increasing
On 21.09.2014 19:17, Boian Mitov wrote:
In general I would prefer to see this implemented with attributes rather
than with new keywords. For god shake, we already have more keywords in
this language than it is healthy. We should be extremely cautions when
adding new ones.
That is one of the
On 21.09.2014 20:28, Boian Mitov wrote:
Ahh... the schizophrenic nature of Object Pascal :-D, I never understood
why interface and class should be different at first place, considering
that interface is practically nothing more than pure abstract class with
ref. counting. Why the separated
45 matches
Mail list logo
