Opened 10 years ago
Last modified 10 years ago
#7838 new Feature Requests
Exposing hander sizes of each call as constants.
| Reported by: | Owned by: | chris_kohlhoff | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | asio |
| Version: | Boost 1.52.0 | Severity: | Cosmetic |
| Keywords: | Cc: |
Description
Hello!
This feature request is related to the CustomHandler api.
As the internal handler storage size is fixed for each async api call (I think...), would it be possible to add constants that inform about the maximum size requirements of each async call?
That would ease the implementation of segregated storage pools storing custom handlers, making it more suitable for realtime use.
For example of what I'm using on x86 linux, I found that an "async_wait" takes 40 bytes, an "async_receive_from" 72, and an "async_send_to" 92.
What I'm doing now is "fake calls" in initialization time, retreiving the requested sizes through a CustomHandler that traces the sizes, and then initializing the segregated storage pools with the results.
That could easily be avoided exposing the size constants in some way.
The current custom handler API wouldn't need to change.
I must say that it was very wise to add the block size to the deallocation call, it eased things a lot, it allowed me to write safety code to forward the allocation/deallocation calls to the heap in case that the size requested wasn't the one.
Best regards! Rafa.
Hello!
This feature request is related to the CustomHandler? api.
As the internal handler storage size is fixed for each async api call (I think...), would it be possible to add constants that inform about the maximum size requirements of each async call?
That would ease the implementation of segregated storage pools storing custom handlers, making it more suitable for realtime use.
For example, in x86 linux I found that an "async_wait" constantly takes 40 bytes, an "async_receive_from" 72, and an "async_send_to" 92.
What I'm doing now is "fake calls" in initialization time, retreiving the requested sizes through a CustomHandler that traces the sizes, and then initializing the segregated storage pools with the results.
That could easily be avoided exposing the size constants in some way.
The current custom handler API wouldn't need to change.
I must say that it was very wise to add the block size to the deallocation call, it eased things a lot, it allowed me to write safety code to forward the allocation/deallocation calls to the heap in case that the size requested wasn't the one.
Best regards! Rafa.