Skip to content

Add conversion functions for writePoolData#1014

Open
koalabearguo wants to merge 1 commit intogorilla:mainfrom
koalabearguo:patch-1
Open

Add conversion functions for writePoolData#1014
koalabearguo wants to merge 1 commit intogorilla:mainfrom
koalabearguo:patch-1

Conversation

@koalabearguo
Copy link

@koalabearguo koalabearguo commented Feb 27, 2026

Because writePoolData is not export,so it can not config WriteBufferPool field in Upgrader and Dialer

What type of PR is this? (check all applicable)

  • Refactor
  • Feature
  • Bug Fix
  • Optimization
  • Documentation Update
  • Go Version Update
  • Dependency Update

Description

Related Tickets & Documents

  • Related Issue #
  • Closes #

Added/updated tests?

  • Yes
  • No, and this is why: please replace this line with details on why tests
    have not been included
  • I need help with writing tests

Run verifications and test

  • make verify is passing
  • make test is passing

Because writePoolData is not export,so it can not config WriteBufferPool field in Upgrader and Dialer

Signed-off-by: koala <koalabearguo@gmail.com>
@mantidsboring
Copy link

Explain the situation where you need to know the type of the value in the pool. Based on the documentation, the type is intentionally hidden.

@koalabearguo
Copy link
Author

koalabearguo commented Feb 28, 2026

the writePoolData struct is not exported,so when impl BufferPool interface Get/Put,it can not return writePoolData type.

the bellow code line 517 use the writePoolData in conn.go ,it will translate the interface fail。

 512         mw.c = c
 513         mw.frameType = messageType
 514         mw.pos = maxFrameHeaderSize
 515 
 516         if c.writeBuf == nil {
 517                 wpd, ok := c.writePool.Get().(writePoolData)
 518                 if ok {
 519                         c.writeBuf = wpd.buf
 520                 } else {
 521                         c.writeBuf = make([]byte, c.writeBufSize)
 522                 }
 523         }
 524         return nil

@koalabearguo
Copy link
Author

Maybe you can give a demo for using BufferPool in Upgrader and Dialer,I can not run progam normal.

@mantidsboring
Copy link

mantidsboring commented Feb 28, 2026

The pool implication stores values with type any. The pool does not need to know the types of the values. Per the documentation in this package, the *sync.Pool type can be used as a pool. *sync.Pool is a good choice for most applicaitons. Example use:

// create a pool
pool := &sync.Pool{}


// use it in the upgrader
u := websocket.Upgrader{
      ...
       WriteBufferPool: pool
}

A trivial implementation with a pool size of of one is:

package mypool

import (
	"sync/atomic"
)

type Pool struct {
	v atomic.Value
}

func (p *Pool) Put(v any) {
	p.v.Store(v)
}

func (p *Pool) Get() any {
	return p.v.Swap(nil)
}

Notice that the pool does not need to know the type of the value.

@koalabearguo
Copy link
Author

Thanks for getting back to me.

I use the bellow code to initial my program as you mentioned.

websocket.DefaultDialer.WriteBufferPool = &sync.Pool{}

but in conn.go bellow,the ok var is false forever,it forever log the "Error.........",the pool is not used!

 517         if c.writeBuf == nil {
 518                 wpd, ok := c.writePool.Get().(writePoolData)
 519                 if ok {
 520                         c.writeBuf = wpd.buf
 521                 } else {
 522                         c.writeBuf = make([]byte, c.writeBufSize)
 523                         log.Println("Error........")
 524                 }
 525         }
 526         return nil
 527 }

@koalabearguo
Copy link
Author

koalabearguo commented Mar 1, 2026

ok,my program has only one byte pool,I dont want websocket to new byteslice,maybe i can manage bytepool outside the websocket package

so this is my requirement,i need conversion functions for writePoolData,just new byteslice outside the package

@mantidsboring
Copy link

Two things:

  • I’m not a maintainer, but if I were, I’d want to see a use case that clearly cannot be solved without this PR.
  • The maintainers haven’t merged a PR in almost a year, even though there are some high-quality submissions. I wouldn’t expect this to be merged anytime soon.

@koalabearguo
Copy link
Author

ok,i see.
thanks.
i has a bytepool in my main package,i just want to reuse the bytepool,this is the key point.
i just opt the memory usage for some docker env which is memory limited.

now i can use it local.so it dose not matter

thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants