On Wed, Jul 10, 2019 at 3:24 PM Roman Kuprov wrote:
>
> Would the Context package not work for this issue?
> (kinda new gopher here)
It is similar to using a cancel channel. Context communicates the
cancellation by closing a channel returned by Done().
>
> On Wednesday, July 10, 2019 at 1:08:38
Would the Context package not work for this issue?
(kinda new gopher here)
On Wednesday, July 10, 2019 at 1:08:38 PM UTC-6, Dan Eloff wrote:
>
> Yeah, agreed. I've been deep into concurrent programming for a long time
> now, and into lock-free programming as well which is the most fraught kind
Yeah, agreed. I've been deep into concurrent programming for a long time
now, and into lock-free programming as well which is the most fraught kind
of programming I've ever done. Parallel is the future, it has been that way
for a long time, but it's only getting more and more obvious.
I think in
On Wed, Jul 10, 2019 at 6:30 PM wrote:
>
> The best thing to do is to not use unmanaged resources.
>
Would be the Erlang solution. You cannot change the owner of an open file,
and if the process owning it terminates, the file is closed. You can change
ownership of a TCP socket, and then
On Wed, Jul 10, 2019 at 6:45 PM Dan Eloff wrote:
> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones
> wrote:
>
>> unbuffered means nothing is sent until is is simultaneously received, so
>> there is no limbo or race or uncertainty. one sender "wins" the select and
>> the others remain blocked
On Wed, Jul 10, 2019 at 10:45 AM Dan Eloff wrote:
>
> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones wrote:
>>
>> unbuffered means nothing is sent until is is simultaneously received, so
>> there is no limbo or race or uncertainty. one sender "wins" the select and
>> the others remain blocked
On Wed, Jul 10, 2019 at 7:54 AM Michael Jones
wrote:
> unbuffered means nothing is sent until is is simultaneously received, so
> there is no limbo or race or uncertainty. one sender "wins" the select and
> the others remain blocked waiting.
>
So I'm correct then: "Now one of two things must
On Tuesday, July 9, 2019 at 12:27:32 PM UTC-4, Dan Eloff wrote:
>
> I couldn't use <-channel.Close since in my case the goroutine isn't
> guaranteed to have something sent, so that would leak goroutines. I added a
> cleanup goroutine to scan timed-out channels and close them, which solves
>
unbuffered means nothing is sent until is is simultaneously received, so
there is no limbo or race or uncertainty. one sender "wins" the select and
the others remain blocked waiting.
On Wed, Jul 10, 2019 at 6:24 AM Dan Eloff wrote:
> Maybe I'm wrong here in my understanding of unbuffered
Maybe I'm wrong here in my understanding of unbuffered channels, but I
don't think so:
Matt says earlier: "Only a buffered channel can "hold" anything. If the
channel is unbuffered, then you are guaranteed that another goroutine has
at least received the item you sent when the send statement
>
> If the channel is unbuffered, there are two parties, S and R (Sender and
> Receiver). If the channel is buffered, it is another party, C (channel).
> The delivery chain is really S -> C -> R. Whereas in the unbuffered case,
> rendezvous means an atomic exchange of the resource (S -> R).
On Tue, Jul 9, 2019 at 6:14 AM Daniel Eloff wrote:
> If a select statement has multiple channels ready when it runs, then it
> will choose one at a random. So if you fire something across a channel that
> holds a resource, like an open file descriptor - you have no guarantees
> that the other
>
>
> And not only that, it's complicated. The language spec is not the
> right place to dig into the complexities of how to use select safely
> while avoiding race conditions. There is just too much to say. And
> there are no docs for select other than the language spec.
>
>
Well here's
On Tue, Jul 9, 2019 at 10:36 AM Daniel Eloff wrote:
>>
>>
>> In my opinion the best place for this kind of discussion is a blog
>> post or talk.
>
>
> I disagree strongly. If there's a mode of operation that's dangerous when I'm
> operating a car or machinery I want it to not just be called out
>
>
> In my opinion the best place for this kind of discussion is a blog
> post or talk.
>
I disagree strongly. If there's a mode of operation that's dangerous when
I'm operating a car or machinery I want it to not just be called out in the
manual, but called attention to in a big bold
On Tue, Jul 9, 2019 at 9:27 AM Dan Eloff wrote:
>
> So I guess the best thing to do in these cases is don't combine select with
> sending unmanaged resources over a channel. It's probably worth warning about
> this problem in the docs for select? It's not an obvious gotcha.
In my opinion the
On Mon, Jul 8, 2019 at 9:14 PM Daniel Eloff wrote:
>
> If a select statement has multiple channels ready when it runs, then it will
> choose one at a random. So if you fire something across a channel that holds
> a resource, like an open file descriptor - you have no guarantees that the
>
On Mon, Jul 8, 2019 at 10:54 PM Tamás Gulácsi wrote:
>
> // Wait on the channel, or for timeout
> select {
> case fd := <-channel:
> return fd, nil
> case <-time.After(queue.timeout):
> // Check again
> select {
> case fd := <-channel:
> return fd, nil
>
// Wait on the channel, or for timeout
select {
case fd := <-channel:
return fd, nil
case <-time.After(queue.timeout):
// Check again
select {
case fd := <-channel:
return fd, nil
default:
return nil, ErrTimeoutElapsed
}
}
--
You received this
Only a buffered channel can "hold" anything. If the channel is unbuffered,
then you are guaranteed that another goroutine has at least received the
item you sent when the send statement returns.
On Mon, Jul 8, 2019 at 9:42 PM Burak Serdar wrote:
> On Mon, Jul 8, 2019 at 10:14 PM Daniel Eloff
On Mon, Jul 8, 2019 at 10:14 PM Daniel Eloff wrote:
>
> If a select statement has multiple channels ready when it runs, then it will
> choose one at a random. So if you fire something across a channel that holds
> a resource, like an open file descriptor - you have no guarantees that the
>
If a select statement has multiple channels ready when it runs, then it
will choose one at a random. So if you fire something across a channel that
holds a resource, like an open file descriptor - you have no guarantees
that the other end of the channel receives it. The (possibly full) channel
22 matches
Mail list logo
