On Tuesday, 13 May 2014 at 15:46:51 UTC, Yuriy wrote:
Hello, I've played a bit with monitors, trying to make them
optional, and here's what i've come up with:
https://github.com/yglukhov/dmd/tree/optional_monitor
https://github.com/yglukhov/druntime/tree/optional_monitors
The whole idea is that
On Tue, 16 Sep 2014 15:01:17 -0400, Sean Kelly
wrote:
Yeah I haven't looked at the implementation yet either.
Currently, it's possible to set a core.sync.Mutex as an object
monitor. Would this capability be preserved? Someone mentioned
a hashtable of monitors... do we really need this? I c
Yeah I haven't looked at the implementation yet either.
Currently, it's possible to set a core.sync.Mutex as an object
monitor. Would this capability be preserved? Someone mentioned
a hashtable of monitors... do we really need this? I can see the
desire to preserve existing semantics and so a u
On Mon, 08 Sep 2014 12:57:13 -0400, Andrei Alexandrescu
wrote:
On 9/8/14, 2:10 AM, Andrej Mitrovic wrote:
On Thursday, 22 May 2014 at 17:25:30 UTC, Steven Schveighoffer wrote:
A possible path is to introduce the change, but put @monitor on
Object. This will allow all current code to compile
On Monday, 8 September 2014 at 16:56:49 UTC, Andrei Alexandrescu
wrote:
FWIW we could do this for backward compatibility: objects
without @monitor use the hashtable, and those with @monitor use
a field.
And that's exactly what current PR suggests. However, it's
stalled due to another issue. Th
On 9/8/14, 2:10 AM, Andrej Mitrovic wrote:
On Thursday, 22 May 2014 at 17:25:30 UTC, Steven Schveighoffer wrote:
A possible path is to introduce the change, but put @monitor on
Object. This will allow all current code to compile as-is.
Then users who are concerned about their code being affecte
On Thursday, 22 May 2014 at 17:25:30 UTC, Steven Schveighoffer
wrote:
A possible path is to introduce the change, but put @monitor on
Object. This will allow all current code to compile as-is.
Then users who are concerned about their code being affected
would be able to remove @monitor from Ob
On Thursday, 22 May 2014 at 06:48:17 UTC, Martin Nowak wrote:
I don't see why we need to introduce a global hashtable
(performance impact, not pure). We could warn/deprecate/remove
synchronizing on classes without the @monitor attribute.
It's not only about synchronization. Signals use monitors
On Thu, 22 May 2014 02:48:16 -0400, Martin Nowak wrote:
On Monday, 19 May 2014 at 07:11:41 UTC, Yuriy wrote:
On Sunday, 18 May 2014 at 19:57:34 UTC, Walter Bright wrote:
The "_monitor" slot is also used for std.signals. It's been set up in
druntime to support more than just being a monitor.
On Monday, 19 May 2014 at 07:11:41 UTC, Yuriy wrote:
On Sunday, 18 May 2014 at 19:57:34 UTC, Walter Bright wrote:
The "_monitor" slot is also used for std.signals. It's been
set up in druntime to support more than just being a monitor.
We've also considered it for a hook for a reference count
If we didn't have to worry about being backwards compatible,
I'd definitely argue for the second solution. Java
compatibility is not a very strong argument in my opinion.
First, porting a Java application 1:1 is asking for
performance hazards (w.r.t. GC, ...) anyway. Second, the
no-synchroniz
On 5/18/14, 7:10 AM, David Nadlinger wrote:
... Java classes could just be
translated to "@synchronizable class" or whatever.
Whether we preserve backwards compatibility or not, @synchronizable has
my vote for the bikeshed's color.
On Sun, 18 May 2014 06:33:55 -0400, Andrei Alexandrescu
wrote:
On 5/17/14, 10:01 PM, Walter Bright wrote:
On 5/14/2014 2:17 PM, Andrei Alexandrescu wrote:
On 5/14/14, 6:33 AM, Yuriy wrote:
4. I consider D a killemall language, that may be potentially used on
tiny AVRs and PICs, where polym
On Sunday, 18 May 2014 at 19:57:34 UTC, Walter Bright wrote:
The "_monitor" slot is also used for std.signals. It's been set
up in druntime to support more than just being a monitor.
We've also considered it for a hook for a reference count
(though that design had other problems).
I'm not sa
On 19/05/14 08:29, Jacob Carlborg wrote:
DWT is still around. Although, I don't have any memory of seeing the
monitor being used.
The "synchronized" statement is used in DWT.
--
/Jacob Carlborg
On 18/05/14 07:01, Walter Bright wrote:
While I agree with Andrei's agreements (!), the rationale for the
current approach is to make it relatively straightforward to translate
existing Java code into D. There was a fair amount of this in the early
days of D, I'm not sure how much of that lately
On 5/13/2014 8:46 AM, Yuriy wrote:
Your feedback is very appreciated. Thanx.
The "_monitor" slot is also used for std.signals. It's been set up in druntime
to support more than just being a monitor.
We've also considered it for a hook for a reference count (though that design
had other prob
On Sunday, 18 May 2014 at 10:33:53 UTC, Andrei Alexandrescu wrote:
Maybe I misunderstood - I thought the change preserves
semantics. -- Andrei
There are two layers to the changes discussed in this thread. The
first is to remove __monitor from Object. This is something I
think we all agree on.
Andrei Alexandrescu:
Maybe I misunderstood - I thought the change preserves
semantics. -- Andrei
Perhaps it's Walter that has misunderstood.
Bye,
bearophile
On 5/17/14, 10:01 PM, Walter Bright wrote:
On 5/14/2014 2:17 PM, Andrei Alexandrescu wrote:
On 5/14/14, 6:33 AM, Yuriy wrote:
4. I consider D a killemall language, that may be potentially used on
tiny AVRs and PICs, where polymorphism might be welcome, but an extra
pointer for each class instan
On Sunday, 18 May 2014 at 05:01:21 UTC, Walter Bright wrote:
While I agree with Andrei's agreements (!), the rationale for
the current approach is to make it relatively straightforward
to translate existing Java code into D. There was a fair amount
of this in the early days of D, I'm not sure h
On Sunday, 18 May 2014 at 04:44:56 UTC, Martin Nowak wrote:
Global hashmap is a bad idea IMO because it's possibly
expensive and impure. Rather deprecate synchronizing on classes
without an explicit monitor.
Totally agreed. Hashmap is done just not to break existing code.
I don't think i've got
On 5/14/2014 2:17 PM, Andrei Alexandrescu wrote:
On 5/14/14, 6:33 AM, Yuriy wrote:
4. I consider D a killemall language, that may be potentially used on
tiny AVRs and PICs, where polymorphism might be welcome, but an extra
pointer for each class instance may become a blocker. I know, thats
fanta
On Wednesday, 14 May 2014 at 09:16:21 UTC, Yuriy wrote:
On Wednesday, 14 May 2014 at 08:37:41 UTC, bearophile wrote:
What's the syntax to define a class without its __monitor? Are
you using an annotation like @no_monitor?
No syntax for that. The __monitor is not present by default
anywhere. If
Yuriy:
http://dpaste.dzfl.pl/f44762a17fe4
As workaround for a D design bug I suggest to write code like
this:
foreach (immutable c; 0 .. 100_000)
Instead of:
foreach(c; 0..10)
Because unfortunately by default that c index is not immutable,
and this causes significant troubles if you m
On Wednesday, 14 May 2014 at 19:08:30 UTC, bearophile wrote:
You are good. Before this is ready for Walter's judgement I
think this needs some simple performance/memory benchmarks, to
compare the situation before and after this change.
I've made some minor optimizations, and rebased everything o
On 5/14/14, 6:33 AM, Yuriy wrote:
On Wednesday, 14 May 2014 at 13:07:32 UTC, bearophile wrote:
I'd like to know why you think D classes should not have the monitor
on default (this means why you don't plan for a @no_pointer).
There are 4 reasons for that.
1. I'm thinking of monitors as members
Yuriy:
Meanwhile, i've updated the PRs according to latest notes.
@monitor attr, forbid __monitor declaration, so everyone can
have some fun with it. =)
You are good. Before this is ready for Walter's judgement I think
this needs some simple performance/memory benchmarks, to compare
the sit
Actually, I prefer your original proposal @no_monitor as I expect
D classes to have monitors by default, until D eventually
changes. Having @monitor implies that by default there are no
monitors (which makes sense, but unfortunatelly that is not the
current state of affairs in D).
On Wednesday, 14 May 2014 at 14:44:07 UTC, Marc Schütz wrote:
The object's layout and size also change, but the layout of
objects is implementation defined AFAIK, and its size shouldn't
be hard-coded anyway, so the breakage is minimal.
You're right. Shared libraries will need to be rebuilt.
Me
On Wednesday, 14 May 2014 at 14:07:50 UTC, Yuriy wrote:
On Wednesday, 14 May 2014 at 13:53:51 UTC, Damian Day wrote:
These would be breaking changes. I see the benefit but...
Breaking, only if someone used to define __monitor in his
class. Which is kinda weird, and according to docs (identifier
On Wednesday, 14 May 2014 at 13:53:51 UTC, Damian Day wrote:
These would be breaking changes. I see the benefit but...
Breaking, only if someone used to define __monitor in his class.
Which is kinda weird, and according to docs (identifiers starting
with __ should are reserved). Or if someone u
Yuriy:
4. I consider D a killemall language, that may be potentially
used on tiny AVRs and PICs, where polymorphism might be
welcome, but an extra pointer for each class instance may
become a blocker. I know, thats fantasy now, but i think it's
crucial to keep this concept of D.
It's wiser
On Wednesday, 14 May 2014 at 11:06:43 UTC, Yuriy wrote:
bearophile, good point. What do you think of the following
solution:
1. Declaring member variable with __monitor identifier is
disallowed.
2. class may be defined with @__monitor attribute, in which
case a __monitor variable will be added
On Wednesday, 14 May 2014 at 13:07:32 UTC, bearophile wrote:
I'd like to know why you think D classes should not have the
monitor on default (this means why you don't plan for a
@no_pointer).
There are 4 reasons for that.
1. I'm thinking of monitors as members of Object class, so all
other cla
Yuriy:
2. class may be defined with @__monitor attribute, in which
case a __monitor variable will be added to it's beginning.
I'd like to know why you think D classes should not have the
monitor on default (this means why you don't plan for a
@no_pointer).
Currently D classes have that poi
On Wednesday, 14 May 2014 at 11:14:47 UTC, bearophile wrote:
I suggest a name like "@monitor". The is no need for the
underscores.
Done.
A more tidy design could require the @monitor in all classes
that inherit from a @monitor-annotated class. But this also
looks a little overkill. So let's h
Yuriy:
2. class may be defined with @__monitor attribute, in which
case a __monitor variable will be added to it's beginning.
I suggest a name like "@monitor". The is no need for the
underscores.
3. Subclass of such class may again be defined with @__monitor
attar, in which case it will b
bearophile, good point. What do you think of the following
solution:
1. Declaring member variable with __monitor identifier is
disallowed.
2. class may be defined with @__monitor attribute, in which case
a __monitor variable will be added to it's beginning.
3. Subclass of such class may again be
Yuriy:
No syntax for that. The __monitor is not present by default
anywhere. If you need it, you need to define one.
class B
{
void* __monitor;
What kind of clear error messages do you receive if you write:
class B {
void* _monitor;
Or:
class B {
size_t __monitor;
This isn'
On Wednesday, 14 May 2014 at 08:37:41 UTC, bearophile wrote:
What's the syntax to define a class without its __monitor? Are
you using an annotation like @no_monitor?
No syntax for that. The __monitor is not present by default
anywhere. If you need it, you need to define one.
class A
{
}
clas
Yuriy:
Your feedback is very appreciated. Thanx.
What's the syntax to define a class without its __monitor? Are
you using an annotation like @no_monitor?
Bye,
bearophile
Ok, i think i've found a simple yet effective solution.
Implemented and pushed to the repo. Any more thoughts before a PR?
The only downside i see here is that finalization of every
object will now lookup for a corresponding monitor, if it's
class doesn't define embedded one.
Ok, i think i've found a simple yet effective solution.
Adding a flag to ClassFlags: hasAllocatedMonitors.
Mark m_flags with this flag in run
On 5/13/14, 8:46 AM, Yuriy wrote:
Hello, I've played a bit with monitors, trying to make them optional,
and here's what i've come up with:
https://github.com/yglukhov/dmd/tree/optional_monitor
https://github.com/yglukhov/druntime/tree/optional_monitors
The whole idea is that Object doesn't conta
13-May-2014 19:46, Yuriy пишет:
Hello, I've played a bit with monitors, trying to make them optional,
and here's what i've come up with:
https://github.com/yglukhov/dmd/tree/optional_monitor
https://github.com/yglukhov/druntime/tree/optional_monitors
The whole idea is that Object doesn't contain
Hello, I've played a bit with monitors, trying to make them
optional, and here's what i've come up with:
https://github.com/yglukhov/dmd/tree/optional_monitor
https://github.com/yglukhov/druntime/tree/optional_monitors
The whole idea is that Object doesn't contain __monitor field
anymore.
TypeI
47 matches
Mail list logo
