I'm having some problems in HTTP library.
The problem is that system function 68, 20 (reallocate memory block) sometimes moves the allocated memory to a new location.
During HTTP transfer, memory block should be resized when more space is needed for the file in transfer.
It would be possible to re-calculcate pointers after memory re-allocation, but then the problem lies in parsing of uncomplete transfers.
It's common for a browser to start parsing the page/image that is not fully transfered, but when the data is moving all the time, this will be very inconvenient.
Who knows a solution?
sysfn 68, 20
-
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
You need yours own memory manager, something like brk()/sbrk(). Allocate a large enough memory block, and use f.68.26 to keep as many pages, as need.
A new system function in kernel, to resize allocated memory is not an option?Serge wrote:You need yours own memory manager, something like brk()/sbrk(). Allocate a large enough memory block, and use f.68.26 to keep as many pages, as need.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
68.20 do thisA new system function in kernel, to resize allocated memory is not an option?
But, user-mode heap (68.12,13,20) is not well designed. If you need something more complicated than "allocate a single block of memory for all the time", better to make your own manager. 68.12 and 68.20 two main functions for creating such manager. The first reserves the required range of addresses. The second lets you keep in this range as many mapped pages as necessary.
OK.
I dont have the ambition to write such a memory manager, so I have updated my library to work with existing implementation (I update all pointers after realloc)
The user of the library may choose to use his own memory manager if he finds it inconvenient that the data is moving.
I dont have the ambition to write such a memory manager, so I have updated my library to work with existing implementation (I update all pointers after realloc)
The user of the library may choose to use his own memory manager if he finds it inconvenient that the data is moving.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Currently, due to poor design is better not to use multiple 68.12 13 20 calls at all.
You don't need a complicated memory manager. Suppose, you need 40Kb ram on average and 2Mb maximum. You create 2Mb block and after library call release the page above 40 Kb if allocation exceed 40 KB. Also you can collect statistics and change the current number of mapped pages as needed.
You don't need a complicated memory manager. Suppose, you need 40Kb ram on average and 2Mb maximum. You create 2Mb block and after library call release the page above 40 Kb if allocation exceed 40 KB. Also you can collect statistics and change the current number of mapped pages as needed.
Who is online
Users browsing this forum: No registered users and 9 guests