Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Plugins
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Unhelpful - 2009-02-16
Last edited by Unhelpful - 2009-03-04

FS#9916 - bufalloc-like memory allocator for use with plugin buffer

This patch adds a set of dynamic allocation routines to the pluginlib, with an API similar to rb→bufalloc.

cons:

not malloc-compatible

pros:

can compact
easy replacement for plugins using bufalloc
can be initialized to allocate from plugin buffer, or any other chunk of contiguous memory
The task blocks this from closing
ID Project Summary Priority Severity Assigned To Progress
9919 Rockbox  FS#9919 - lib/buffer_alloc support in pictureflow  Very Low Low
100%
Closed by  Unhelpful
2009-03-04 21:11
Reason for closing:  Accepted
Additional comments about closing:  

commited as r20202

You seem to have forgotten your attachment?

MikeS commented on 2009-02-16 22:36

Yeah, has your desire to work on this turned into a feature request? Should I change the task type? :p

MikeS commented on 2009-02-17 00:27

This indeed could be very useful for mpegplayer but would need to be dual-core safe since libmpeg2 will call it repeatedly. Perhaps an automatic buffer alignment switch instead of nastying up the code with calls? Perhaps a more thread/core-hardened extension layer could exist in the lib if an app needs that?

whitespace fixes and docs

Track compact/sparse status of buffer (may be falsely marked sparse under some use patterns, should never be falsely marked compact), and base retries during allocation on this status, rather than always trying to compact once. Also fix a bug where compaction after allocating a handle, but before buffer allocation, could cause the handle table to be “shrunk” below the allocated handle. This could have resulted in a handle being issued twice, if the compaction caused the alloc to succeed on retry.

Correct update of handle table entries during compaction, update first_free_block on completing compaction, both caused buffer corruption.

What’s the purpose of the global_context struct, and wrapping the API functions with macros that pass that into buffer_alloc.c ?

Couldn’t that struct either be declared local to buffer_alloc.c (and hence remove the need for those macros and the extra parameter), or openly declared in the plugin using buffer_alloc.c ? Either of those would be cleaner IMO (unless I’m missing a reason for it to be the way it is - I’ve only looked at the patch briefly).

Per Dave’s suggestions, the context is now always defined and passed explicitly by the caller. The _ctx function suffix is also removed, and the buf_ prefix is now buflib, and the files buflib.c/h to avoid confusion with core files or functions. Header comments and include guards have also been added.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing