Linked by Thom Holwerda on Tue 7th Aug 2007 17:31 UTC, submitted by GhePeU
Gnome "About half a year ago I was looking around me and seeing stagnation in the GNOME community. I was concerned that GNOME had lost its momentum and that we were just making boring incremental releases that added very little new functionality. I think I was very wrong. I'd like to take this time to list some things that are happening right now in the GNOME community that have me very excited. These are the projects that are actively improving the future of the GNOME desktop." Let's hope a punctuation checker will be part of GNOME too. One Aaron is enough.
Thread beginning with comment 261837
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: go vala!
by renox on Wed 8th Aug 2007 15:26 UTC in reply to "RE[5]: go vala!"
renox
Member since:
2005-07-06

>Normal GC are not bounds ? Neither are normal malloc.
Sigh, you know as well as me that the big difference is that a GC can run at any time but with malloc/free, there can be a delay only when you call malloc or free, so it's easy to avoid pause in normal software: preallocate before the time sensitive part, with a GC either you have also to disable the GC collection or you use a real-time GC.

>ps -e. Beos responsiveness has nothing to do with multi threading per se
So how do you explain it?
The link you gave didn't say that BeOS wasn't threaded, just that it's hard to do threaded programming (a well-known fact).
AFAIK all BeOS applications had at least two threads: one for the window, one for the application core and IMHO this had a lot of impact on the responsiveness felt.

Reply Parent Score: 4

RE[7]: go vala!
by ashigabou on Thu 9th Aug 2007 01:10 in reply to "RE[6]: go vala!"
ashigabou Member since:
2005-11-11

Sigh, you know as well as me that the big difference is that a GC can run at any time but with malloc/free, there can be a delay only when you call malloc or free, so it's easy to avoid pause in normal software: preallocate before the time sensitive part, with a GC either you have also to disable the GC collection or you use a real-time GC.


The solution is not only to preallocate malloc, but to do all the computation in a separate thread, without any unbound operations: no malloc, no locking, etc... The thread can then be efficiently scheduled using SCHEDULE_FIFO, for example. If you do everything in a different thread, you can also disable the GC for this thread. But anyway, this is really not the problem that vala is trying to solve, so I don't see how it is relevant.

AFAIK all BeOS applications had at least two threads: one for the window, one for the application core and IMHO this had a lot of impact on the responsiveness felt.


JBQ explains exactly why on the contary, BeOS was not responsive because of the multi threaded API, but for other reasons. This is a really interesting thread

Reply Parent Score: 1