search

netty / netty

Netty project - an event-driven asynchronous network application framework
http://netty.io
Apache License 2.0
33.28k stars 15.89k forks source link

ByteBufAllocator.ioBuffer() of dubious value? #6606

Open trustin opened 7 years ago

trustin commented 7 years ago

Currently, ByteBufAllocator.buffer() allocates a direct buffer if:

ByteBufAllocator.ioBuffer() differes from buffer() only in that it does not respect the io.netty.noPreferDirect.

I'm not sure if it makes sense not to respect io.netty.noPreferDirect for ioBuffer(). Should we probably just deprecate ioBuffer() in favor of buffer()?

Mr00Anderson commented 7 years ago

I was wondering the same thing. The only instance I can think that this is important is for client applications where developer may want to the user to be overridden and not have their option work. However I support clean up.

normanmaurer commented 7 years ago

@trustin sounds good.

Scottmitch commented 7 years ago

Why would ioBuffer return a heap buffer? I would assume most/all IO destinations would ultimately require a direct buffer anyways, no?

normanmaurer commented 7 years ago

@Scottmitch for example if you use the OIO transport it is preferred to use a heap buffer as you write / read into byte arrays.

Scottmitch commented 7 years ago

I see. If the primary differentiator is the transport (which the allocator has no knowledge of anyways) we should get rid of these methods (deprecate them).

normanmaurer commented 7 years ago

+1

Am 28.04.2017 um 08:18 schrieb Scott Mitchell notifications@github.com:

I see. If the primary differentiator is the transport (which the allocator has no knowledge of anyways) we should get rid of these methods (deprecate them).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.