FYI
https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/
在2020年11月16日星期一 UTC+8 上午9:19:59 写道：
>
> For example, some local memory allocations could be detected no used
> elsewhere so that they can may be freed immediately when out of reach
> instead of waiting to be freed
在2020年11月15日星期日 UTC+8 下午12:19:07 写道：
> On Sat, Nov 14, 2020 at 7:54 PM Robert Engels
> wrote:
>
>> I don’t think a ring buffer works. At least in a traditional ring buffer
>> the producer cannot pass the consumer - if the buffer is full the producer
>> blocks or drops. Trying to ensure the co
在2020年11月14日星期六 UTC+8 上午3:09:24 写道：
> If I understand what you're trying to do, I'd approach it this way, using
> a generously buffered channel and discarding the extras at the consumer, as
> shown below, instead of at the producer:
>
> result <- c // wait for result to appear
> for len(c) > 0
在2020年11月13日星期五 UTC+8 下午11:19:46 写道：
> On Thu, Nov 12, 2020 at 11:13 PM 陶青云 wrote:
> >
> >
> > It is not a one-length buffered channel. I need to drop because the
> recveiver do heavy work that can't process as quickly as sender.
>
> Don't use chann
It is not a one-length buffered channel. I need to drop because the
recveiver do heavy work that can't process as quickly as sender.
在2020年11月13日星期五 UTC+8 下午2:36:13 写道：
> On Thu, Nov 12, 2020 at 9:32 PM 陶青云 wrote:
>
>> Thanks. I want the receiver always get the relately ne
ed channel
select {
case c <- result:
default:
// full, drop old one
go func() {
<-c
c <- result
}()
}
```
在2020年11月13日星期五 UTC+8 上午11:27:23 写道：
> On Thu, Nov 12, 2020 at 6:19 PM 陶青云 wrote:
>
>> ```
>>
> // c is buffered channel
>
```
// c is buffered channel
select {
case c <- result:
default:
// full, drop old one
<-c
c <- result
}
```
I have a code like this, but there may be a race condition in the default
case. I enconter a
deadlock that the goroutine block on 'c<'.
--
You received this message
work.cycles defined as uint32. Assuming gc happens every 2ms, it take
(1 << 32) / 500 / (24 * 3600) = 99 days to overflow. it seems possible.
gcWaitOnMark use (n > work.cycles) test, is this a problem here?
```
// gcWaitOnMark blocks until GC finishes the Nth mark phase. If GC has
// alre
