That they do not work is an important issue as has been explained here
repeatedly.
On Fri, Feb 22, 2019 at 7:59 PM Victor Giordano
wrote:
> Those idioms should be documented somewhere!
>
> I would use waiting groups for the rest of the job, i don't know.. have to
> think a little more.. you got
Those idioms should be documented somewhere!
I would use waiting groups for the rest of the job, i don't know.. have to
think a little more.. you got the number of background task to wait for,
right?
El jueves, 21 de febrero de 2019, 10:47:07 (UTC-3), Jan Mercl escribió:
>
> On Thu, Feb 21,
It is fairly trivial to create a Spawner structure that wraps the wait group
and the counter (max spawns) to do what you want. As others pointed out,
waitempty can be racy in the general sense, and prone to incorrect usage. (I
did not do a full analysis but I’ll take your word for it that it is
Yes workers could regulate number of spawns with an atomic counter
themselves but how would the "master caller" sleep until all those workers
are done? It needs to sleep until the counter is zero, Like a WaitGroup.
22 Şub 2019 Cum 15:53 tarihinde Robert Engels şunu
yazdı:
> But you can replace
But you can replace waitempty() and related with a simple atomic counter
variable and avoid channels for this. Far simpler.
> On Feb 22, 2019, at 6:38 AM, Serhat Sevki Dincer wrote:
>
> A little imagination would help us all greatly. Select part would obviously
> be in a for loop. Like
A little imagination would help us all greatly. Select part would obviously
be in a for loop. Like this:
func worker() {
// do work, prepare whatever
for some_condition{
// do stuff
Select {
ch <- true:
go worker() // try to handover some jobs
default:
// max goroutine limit
I’m pretty sure this code is incorrect and there will only be a single routine
doing any “real work”, although the comment //do remaining jobs is unclear
because there is no code.
> On Feb 22, 2019, at 12:42 AM, Serhat Şevki Dinçer wrote:
>
> Another use case is wait groups with Max number
Forgot to start it :P
func main() {
waiter()
}
22 Şub 2019 Cum 09:56 tarihinde Kurtis Rader şunu
yazdı:
> I don't see where your `waiter()` function is used in your example. I have
> been lurking till now but I concur with the other people who have told you
> your proposal doesn't make any
I don't see where your `waiter()` function is used in your example. I have
been lurking till now but I concur with the other people who have told you
your proposal doesn't make any situation easier to deal with and in fact is
likely to be the source of bugs.
On Thu, Feb 21, 2019 at 10:43 PM
Another use case is wait groups with Max number of goroutines allowed:
ch:= make(chan bool, 10)
func waiter() {
ch <-true
go worker()
// when empty, all jobs are finished
waitempty(ch)
}
func worker() {
// do work
Select {
ch <- true:
go worker() // try to handover some jobs
By condition variable I mean sync.Cond
> On Feb 21, 2019, at 3:10 PM, Robert Engels wrote:
>
> The proper solution is using a condition variable. You can handle the
> proposed use case easily. There is no need for it to be specific to channels,
> but you need another layer.
>
>> On Feb 21,
The proper solution is using a condition variable. You can handle the proposed
use case easily. There is no need for it to be specific to channels, but you
need another layer.
> On Feb 21, 2019, at 2:49 PM, Burak Serdar wrote:
>
>> On Thu, Feb 21, 2019 at 1:44 PM Serhat Şevki Dinçer
>>
On Thu, Feb 21, 2019 at 1:44 PM Serhat Şevki Dinçer wrote:
>
> On Thursday, February 21, 2019 at 11:21:11 PM UTC+3, Jan Mercl wrote:
>>
>> But then calling it or not has the exact same semantics. So what's it even
>> good for?
>
>
> Let's take your case Jan:
>
> func consumer() {
> select {
Serhat, imagine your feature in the context of a buffered channel that
holds 10 elements, and a writer go routine that wants to send 1000 elements
through that channel.
It is natural to imagine a downstream go routine reading and working on the
first element, and the writer filling the empty slot
On Thursday, February 21, 2019 at 11:21:11 PM UTC+3, Jan Mercl wrote:
>
> But then calling it or not has the exact same semantics. So what's it even
> good for?
>
Let's take your case Jan:
func consumer() {
select {
case x := <-ch:
// received, consume x
default:
//
But then calling it or not has the exact same semantics. So what's it even
good for?
On Thu, Feb 21, 2019, 21:17 Serhat Şevki Dinçer wrote:
> btw waitempty(ch) does not return any value, and it does not (have to)
> guarantee that ch stays empty when it returns..
>
>
> On Thursday, February 21,
On Thu, Feb 21, 2019 at 1:10 PM Serhat Şevki Dinçer wrote:
>
> Burak, I think you dont get the potential of the suggesred directives.
>
> You can be interested in waitepty(ch) for example when:
> - you have direct control of who is pushing and pulling on it, and you know
> what an empty buffer
btw waitempty(ch) does not return any value, and it does not (have to)
guarantee that ch stays empty when it returns..
On Thursday, February 21, 2019 at 11:10:45 PM UTC+3, Serhat Şevki Dinçer
wrote:
>
> Burak, I think you dont get the potential of the suggesred directives.
>
> You can be
Hi rog,
As -> and <- are 'not racy', because they are 'core' language features,
because runtime handles them, because they are guaranteed to 'work', I am
asking how easy and useful to implement them as 'core' language features.
Thank you..
On Thursday, February 21, 2019 at 9:04:22 PM UTC+3,
As others have said, such operations are inherently racy - when you receive
the message that a channel is empty, it may not be empty any more. For that
reason, it's not a good idea to add them as primitives to the language.
That said, it's not too hard to implement them yourself. We are talking
21 Şub 2019 Per 17:12 tarihinde Burak Serdar şunu yazdı:
> On Thu, Feb 21, 2019 at 6:51 AM Serhat Sevki Dincer
> wrote:
> >
> > But observer goroutines are not supposed to push to or pull from the
> channel.
>
> What is a use case for observing a channel like this? If you call
> waitempty(ch),
No but you can for example have a second channel from the pusher to the
observer that signals (in case it cannot push anymore) the latter that the
channel to which it tries to push to is full.
The opposite is true from the consumer, that could signal via a second
channel, when it cannot pull from
meant has no guarantee
21 Şub 2019 Per 17:18 tarihinde Serhat Sevki Dincer
şunu yazdı:
> 21 Şub 2019 Per 17:12 tarihinde Burak Serdar şunu
> yazdı:
>
>> On Thu, Feb 21, 2019 at 6:51 AM Serhat Sevki Dincer
>> wrote:
>> >
>> > But observer goroutines are not supposed to push to or pull from the
But observer goroutines are not supposed to push to or pull from the
channel.
21 Şub 2019 Per 16:46 tarihinde Jan Mercl <0xj...@gmail.com> şunu yazdı:
> On Thu, Feb 21, 2019 at 2:38 PM Serhat Şevki Dinçer
> wrote:
>
> > waitempty(ch)
> > blocks caller until ch buffer is empty
>
> Not exactly
On Thu, Feb 21, 2019 at 2:38 PM Serhat Şevki Dinçer
wrote:
> waitempty(ch)
> blocks caller until ch buffer is empty
Not exactly the same, but a similar mechanism exists:
select {
case x := <-ch:
...
default:
... ch is empty
}
>
Hi,
Say you have a buffered channel
ch := make(chan int, 10)
Would it make sense and be easy to add the following directives to the Go
language core?
waitempty(ch)
blocks caller until ch buffer is empty
waitfull(ch)
blocks caller until ch buffer is full
This means there are 3 types of
26 matches
Mail list logo
