Linked by Thom Holwerda on Tue 7th Aug 2007 17:31 UTC, submitted by GhePeU
Thread beginning with comment 261837
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
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




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.