the get_system_info_test.cpp fails

[kaoutsis]

the get_system_info_test.cpp always fails on Haiku; on beos however passes successfully.

I will also attach the memory_monitor.cpp which shows clearly that the memory is freed, and the get_system_info succeeded on haiku (if the events are monitored from another team).

the problem may be:

• thread can't get the updated system infos,

namely, get_sytem_info fails inside the thread that performs the changes to the resources. or

• free() although has freed the memory, the

thread hasn't been notified for this event. or both?

[kaoutsis]

the test app

[kaoutsis]

a simple memory monitor

[axeld]

Memory management works very differently on both systems, and that test just cannot work for Haiku. You could use create_area() instead, but even that could only work reliably if that's the only running app, and there are no driver running that might need memory...

[kaoutsis]

Replying to axeld:

Memory management works very differently on both systems, and that test just cannot work for Haiku. You could use create_area() instead, but even that could only work reliably if that's the only running app, and there are no driver running that might need memory...

the get_system_info_test.cpp: allocates a chunk of 64 MB, then free() is called, and then the thread asks the system through get_system_info() to know how much free memory is there, which should be the number of pages before the allocation; is that invalid?

[axeld]

Yes, as you never know how the allocator works. It might not immediately free the memory, but cache it in some way, or parts of it.

Also, any other system service might have needed memory in the mean time (including the possibility of paging in parts of your own executable), and that is totally unpredictable, since you're measuring the global amount of free pages.

[kaoutsis]

Replying to axeld:

Yes, as you never know how the allocator works. It might not immediately free the memory, but cache it in some way, or parts of it.

Also, any other system service might have needed memory in the mean time (including the possibility of paging in parts of your own executable), and that is totally unpredictable, since you're measuring the global amount of free pages.

Ok, thanks! a) so the memory_monitor.cpp is invalid also? it seems to work. b) how can someone retrieve infos with the use of get_system_info in a safety manner?

[axeld]

Whatever get_system_info() returns is a momentary report on resource usage. The only thing safe about this is that if you'd crash in that function (KDL), the results would accurately describe the current status quo. You also cannot measure how much memory a specific application is actually using vs. how much it has reserved (ie. cached).

Since memory_monitor.cpp does not make any assumptions about the values it prints out, it's of course okay. The number of free pages only count those pages that are actually not used by the system at all (ie. are either in the free or clear page queue). HTH :-)

[kaoutsis]

Replying to axeld:

Whatever get_system_info() returns is a momentary report on resource usage. The only thing safe about this is that if you'd crash in that function (KDL), the results would accurately describe the current status quo. You also cannot measure how much memory a specific application is actually using vs. how much it has reserved (ie. cached).

Since memory_monitor.cpp does not make any assumptions about the values it prints out, it's of course okay. The number of free pages only count those pages that are actually not used by the system at all (ie. are either in the free or clear page queue). HTH :-)

yes, it's more clear now, thanks! the "sin" line is:

	if (tempInfo.used_pages == info.used_pages) {
		// Still the get_system_info shows the allocated pages.