On 2012-03-10 00:04, Nick Sabalausky wrote:
> Freezing things against breaking changes is all fine and good, but NOT
> before they're reached a point where they're good enough to be frozen.
> Premature freezing is how you create cruft and other such shit. Let's not go
> jumping any guns here.
>
>

I completely aggree.

-- 
/Jacob Carlborg

On Sat, Mar 10, 2012 at 04:35:26PM +0100, "Jérôme M. Berger" wrote:
> Adam D. Ruppe wrote:
> > On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
> >> Since when is mouse movement a stop-the-world event on Linux?
> > 
> > It's a hardware interrupt. They all work that way. You have
> > to give a lot of care to handling them very quickly and
> > not letting them stack up (lest the whole system freeze).
> 
> 	So? It's not stop-the-world. While one core is handling the
> interrupt, the other(s) is(are) still running. A stop-the-world GC
> would need to block all threads on all cores while running.
> 
> 		Jerome
> 
> PS: This is nothing restricted to Linux. Windows, MacOS X and the *BSDs have the same behaviour.
[...]

OK, clearly I wasn't understanding what the OP was talking about. It *seemed* to imply that Linux had stop-the-world problems with mouse movement, but this isn't the case.

A hardware interrupt is a hardware interrupt. Whatever OS you're using, it's got to stop to handle this somehow. I don't see how else you can do this. When the hardware needs to signal the OS about something, it's gotta do it somehow. And hardware often requires top-priority stop-the-world handling, because it may not be able to wait a few milliseconds before it's handled. It's not like software that generally can afford to wait for a period of time.

As for Win95 being unable to keep up with mouse movement... well, to be honest I hated Win95 so much that 90% of the time I was in the DOS prompt anyway, so I didn't even notice this. If it were truly a problem, it's probably a sign of poor hardware interrupt handling (interrupt handler is taking too long to process events). But I haven't seen this myself either.


T

-- 
Lottery: tax on the stupid. -- Slashdotter

On 03/10/2012 05:35 AM, Walter Bright wrote:
> On 3/9/2012 3:14 PM, bearophile wrote:
>> D will naturally progressively slow down the rhythm of its new breaking
>> changes, but even very old languages introduce some breaking changes (see
>> some of the changes in C++11),
>
> What breaking changes are there in C++11, other than dumping export?

I am only aware of those, but I don't use C++ a lot. So there might be more:

- introduction of constexpr messed with the overload resolution rules.
- '>>' can no longer be used inside a template argument expression.

On Saturday, 10 March 2012 at 15:27:00 UTC, H. S. Teoh wrote:
> On Sat, Mar 10, 2012 at 04:23:43PM +0100, Adam D. Ruppe wrote:
>> On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
>> >Since when is mouse movement a stop-the-world event on Linux?
>> 
>> It's a hardware interrupt. They all work that way. You have
>> to give a lot of care to handling them very quickly and
>> not letting them stack up (lest the whole system freeze).
>
> Sure, but I've never seen a problem with that.

Neither the OS developers, especially when they are on 999kTB ram and 1billion core processors.

On Saturday, 10 March 2012 at 16:22:41 UTC, H. S. Teoh wrote:

> OK, clearly I wasn't understanding what the OP was talking about. It
> *seemed* to imply that Linux had stop-the-world problems with mouse
> movement, but this isn't the case.
>
> A hardware interrupt is a hardware interrupt. Whatever OS you're using,
> it's got to stop to handle this somehow. I don't see how else you can do
> this. When the hardware needs to signal the OS about something, it's
> gotta do it somehow. And hardware often requires top-priority
> stop-the-world handling, because it may not be able to wait a few
> milliseconds before it's handled. It's not like software that generally
> can afford to wait for a period of time.
>
> As for Win95 being unable to keep up with mouse movement... well, to be
> honest I hated Win95 so much that 90% of the time I was in the DOS
> prompt anyway, so I didn't even notice this. If it were truly a problem,
> it's probably a sign of poor hardware interrupt handling (interrupt
> handler is taking too long to process events). But I haven't seen this
> myself either.

Design of input handling, the theoretical part is irrelevant. I was solely talking about how they do it in practice. OSs are simply unresponsive and in linux it is more severe. If i am having this issue in practice it doesn't matter if it was the GC lock or an another failure to handle input.

On Sat, Mar 10, 2012 at 06:41:24PM +0100, so wrote:
> On Saturday, 10 March 2012 at 15:27:00 UTC, H. S. Teoh wrote:
> >On Sat, Mar 10, 2012 at 04:23:43PM +0100, Adam D. Ruppe wrote:
> >>On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
> >>>Since when is mouse movement a stop-the-world event on Linux?
> >>
> >>It's a hardware interrupt. They all work that way. You have
> >>to give a lot of care to handling them very quickly and
> >>not letting them stack up (lest the whole system freeze).
> >
> >Sure, but I've never seen a problem with that.
> 
> Neither the OS developers, especially when they are on 999kTB ram and 1billion core processors.
[...]

Um... before my recent upgrade (about a year ago), I had been using a
500MB (or was it 100MB?) RAM machine running a 10-year-old processor.
And before *that*, it was a 64MB (or 32MB?) machine running a
15-year-old processor...

Then again, I never believed in the desktop metaphor, and have never seriously used Gnome or KDE or any of that fluffy stuff. I was on VTWM until I decided ratpoison (a mouseless WM) better suited the way I worked.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??

On Sat, Mar 10, 2012 at 06:49:02PM +0100, so wrote:
> On Saturday, 10 March 2012 at 16:22:41 UTC, H. S. Teoh wrote:
[...]
> >As for Win95 being unable to keep up with mouse movement... well, to be honest I hated Win95 so much that 90% of the time I was in the DOS prompt anyway, so I didn't even notice this. If it were truly a problem, it's probably a sign of poor hardware interrupt handling (interrupt handler is taking too long to process events). But I haven't seen this myself either.
> 
> Design of input handling, the theoretical part is irrelevant. I was solely talking about how they do it in practice. OSs are simply unresponsive and in linux it is more severe. If i am having this issue in practice it doesn't matter if it was the GC lock or an another failure to handle input.

Then you must be running a very different Linux from the one I use. In my experience, it's Windows that's an order of magnitude less responsive due to constant HD thrashing (esp. on bootup, and then periodically thereafter) and too much eye-candy.

(Then again, I don't use graphics-heavy UIs... on Linux you can turn most of it off, and I do, but on Windows you have no choice. So perhaps it's more a measure of how I configured my system than anything else. I tried doing this in Windows once, and let's just say that I'll never, ever, even _dream_ of attempting it again, it was that painful.)


T

-- 
I'm still trying to find a pun for "punishment"...

On Saturday, 10 March 2012 at 17:51:28 UTC, H. S. Teoh wrote:

> Um... before my recent upgrade (about a year ago), I had been using a
> 500MB (or was it 100MB?) RAM machine running a 10-year-old processor.
> And before *that*, it was a 64MB (or 32MB?) machine running a
> 15-year-old processor...
>
> Then again, I never believed in the desktop metaphor, and have never
> seriously used Gnome or KDE or any of that fluffy stuff. I was on VTWM
> until I decided ratpoison (a mouseless WM) better suited the way I
> worked.

I am also using light window managers. Most of the time only tmux and gvim running. I tried many WMs but if you are using it frequently and don't like falling back to windows and such, you need a WM working seamlessly with GUIs. Gimp is one. (You might not believe in desktop but how would you use a program like Gimp?) Now most of the tiling WMs suck at handling that kind of thing. Using xmonad now, at least it has a little better support.

On 10-03-2012 18:58, H. S. Teoh wrote:
> On Sat, Mar 10, 2012 at 06:49:02PM +0100, so wrote:
>> On Saturday, 10 March 2012 at 16:22:41 UTC, H. S. Teoh wrote:
> [...]
>>> As for Win95 being unable to keep up with mouse movement... well, to
>>> be honest I hated Win95 so much that 90% of the time I was in the DOS
>>> prompt anyway, so I didn't even notice this. If it were truly a
>>> problem, it's probably a sign of poor hardware interrupt handling
>>> (interrupt handler is taking too long to process events). But I
>>> haven't seen this myself either.
>>
>> Design of input handling, the theoretical part is irrelevant. I was
>> solely talking about how they do it in practice. OSs are simply
>> unresponsive and in linux it is more severe. If i am having this issue
>> in practice it doesn't matter if it was the GC lock or an another
>> failure to handle input.
>
> Then you must be running a very different Linux from the one I use. In
> my experience, it's Windows that's an order of magnitude less responsive
> due to constant HD thrashing (esp. on bootup, and then periodically
> thereafter) and too much eye-candy.

This. On the other hand, OS X has all the eye candy and is still extremely responsive. ;)

>
> (Then again, I don't use graphics-heavy UIs... on Linux you can turn
> most of it off, and I do, but on Windows you have no choice. So perhaps
> it's more a measure of how I configured my system than anything else. I
> tried doing this in Windows once, and let's just say that I'll never,
> ever, even _dream_ of attempting it again, it was that painful.)
>
>
> T
>

-- 
- Alex

On 3/9/2012 10:44 PM, Nick Sabalausky wrote:
> If we start freezing things now, we're going to be Windows 9x.

Win9x was incredibly successful (!) We can only hope to be so successful.