BookinglyTech News
Software

Rust avanza en la estabilización de allocadores personalizados

La comunidad de Rust ha consolidado la API de allocadores, abriendo la puerta a su uso dinámico y mejorando la seguridad al prohibir el unwind durante la asignación.

2 min de lecturaLobsters0 vistas

Rust avanza en la estabilización de allocadores personalizados

La última actualización de la API de allocadores en Rust, publicada el 9 de septiembre de 2026, consolida la forma de los allocadores y abre la posibilidad de usar un allocador dinámico. La nueva interfaz, basada en la PR #156882, reduce el surface area a dos métodos esenciales:

unsafe trait Allocator {
    fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError>;
    unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout);
}

Con esta base, las estructuras estándar como Box y Vec reciben variantes *_in que aceptan cualquier impl Allocator. El soporte para dyn Allocator se habilita inmediatamente, lo que permite crear allocadores en tiempo de ejecución sin pérdida significativa de rendimiento.

Prohibición del unwind

Una de las mejoras más significativas es la prohibición de “unwind” sobre allocadores. Antes, una excepción durante operaciones como Vec::resize podía dejar a la colección en un estado inconsistente, desencadenando double frees cuando el destructor se ejecutaba. Con la nueva política, la asignación y la desasignación se vuelven atómicas respecto a los desbordamientos de panic, lo que elimina un vector de vulnerabilidades.

Limitaciones actuales

Aún quedan áreas sin cubrir: el soporte para contenedores distintos de Vec y Box está ausente, y varios métodos de Vec siguen siendo inaccesibles a través de allocadores personalizados. Además, la interacción entre Drop y Clone sigue siendo un tema de debate; el ejemplo de Arc con un allocador que libera memoria en su destructor muestra la posibilidad de double free si el clon no se gestiona con cuidado.

El equipo de libs liderado por Nia ha impulsado la discusión, y el trabajo continúa en los issues de GitHub y en la comunidad Zulip.

Próximos pasos

Se espera que la comunidad aporte más casos de uso y que se amplíe el soporte a otros tipos de contenedores. Mientras tanto, los desarrolladores que necesiten allocadores personalizados pueden comenzar a experimentar con la API actual, consciente de las limitaciones y de la necesidad de manejar explícitamente el ciclo de vida de los allocadores.

En resumen, Rust está más cerca que nunca de un modelo de allocador robusto y flexible, pero el camino aún no termina.