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 problems).

I'm not saying your design is wrong, just that we should consider what to do with these other issues.

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.

DWT is still around. Although, I don't have any memory of seeing the monitor being used.

-- 
/Jacob Carlborg

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 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 saying your design is wrong, just that we should consider what to do with these other issues.

My current PR doesn't affect that also. The signals and finalization callbacks do work as they used to. What changes is just monitors are looked up in an external hash table, when they are not declared inside the class, by applying @monitor attr to it. synchronized blocks are also not affected in the same way.
However, if you're planning to use monitors for reference counting, such external lookup may become a huge performance issue. But current reference counts of monitors themselves are not an issue at all.

I'm on my way to DConf now, so we can talk about details there if you wish.

On Sun, 18 May 2014 06:33:55 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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 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.
>>>
>>> Agreed at least with the "killing the mall" part :o).
>>
>> 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.
>
> Maybe I misunderstood - I thought the change preserves semantics. --

You didn't misunderstand. The change will use an external monitor stored in a global hashtable if an internal monitor does not exist. synchronized(obj) will always work, even if the object does not contain a monitor field.

-Steve

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.

> 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-synchronized-by-default design allows for clear error messages that immediately suggest the correct fix (add an attribute to the class declaration), and for mechanical porting, Java classes could just be translated to "@synchronizable class" or whatever.

I think deprecating the old behavior is the right choice here.

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 (though that design had other problems).
>>
>> I'm not saying your design is wrong, just that we should consider what to do with these other issues.
>
> My current PR doesn't affect that also. The signals and finalization callbacks do work as they used to. What changes is just monitors are looked up in an external hash table, when they are not declared inside the class, by applying @monitor attr to it. synchronized blocks are also not affected in the same way.
> However, if you're planning to use monitors for reference counting, such external lookup may become a huge performance issue. But current reference counts of monitors themselves are not an issue at all.
>
> I'm on my way to DConf now, so we can talk about details there if you wish.

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.

On Thu, 22 May 2014 02:48:16 -0400, Martin Nowak <code@dawg.eu> 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.
>>>
>>> We've also considered it for a hook for a reference count (though that design had other problems).
>>>
>>> I'm not saying your design is wrong, just that we should consider what to do with these other issues.
>>
>> My current PR doesn't affect that also. The signals and finalization callbacks do work as they used to. What changes is just monitors are looked up in an external hash table, when they are not declared inside the class, by applying @monitor attr to it. synchronized blocks are also not affected in the same way.
>> However, if you're planning to use monitors for reference counting, such external lookup may become a huge performance issue. But current reference counts of monitors themselves are not an issue at all.
>>
>> I'm on my way to DConf now, so we can talk about details there if you wish.
>
> 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.

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 Object, recompile druntime and phobos (once we make it work) and allow people to see how their code breaks without being left hanging (the shipping compiler would still have @monitor).

Then eventually, we can remove @monitor from Object, and users who still wish to force @monitor on Object can do so (recompile druntime and phobos with @monitor added).

-Steve

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 to receive finalization callbacks.