Ø So a goroutine has storage for every possible select in the program? If you
do it statically, that's a lot of storage. If you do it dynamically, then you
have a dynamic select -> nextcase map you have to maintain.
Ø You can put that storage on the stack, but just barely: it has to live as
On Saturday, October 28, 2017 at 11:11:02 PM UTC-7, John Souvestre wrote:
>
> Ø Round robin isn't implementable. There's no place to store the state
> for an individual select.
>
>
>
> Couldn’t a place be allocated? Since it would be local to a goroutine,
> put it on the stack.
>
>
>
>
Ø Round robin isn't implementable. There's no place to store the state for an
individual select.
Couldn’t a place be allocated? Since it would be local to a goroutine, put it
on the stack.
Ø I'm not sure how you would even define round robin. What's the unit that's
being round-robi
Here is a simple solution. Write some middleware that will wrap your
http.Handlers.
In order to handle at most 100 requests the middleware needs to have access
to a channel with a buffer size of 100 (I'll call it x) and do the
following:
1. Send to x
2. Defer a receive from x.
3. Run the origi
You might want to take a look at this video https://youtu.be/ySy3sR1LFCQ which
shows some common issues with concurrency in go and how to use pprof and
the go tracer to inspect and fix them.
Hope this helps a bit.
Yannic
On Friday, October 27, 2017 at 2:38:00 PM UTC+2, Christian LeMoussel wrot
On Saturday, October 28, 2017 at 2:18:05 PM UTC-7, T L wrote:
>
>
>
> On Saturday, October 28, 2017 at 4:56:42 PM UTC-4, T L wrote:
>>
>> In my opinion, the memory model article should mention that if event A
>> happens event B,
>> the the statements shown before event A in source code will be e
On Saturday, October 28, 2017 at 2:59:53 PM UTC-7, John Souvestre wrote:
>
> Ø I don't think it needs to be uniformly fair. It just needs to prevent
> starvation of a channel for infinity. Any proof would have progress covered
> if we pick every channel once in a while, even under a heavily unfa
see https://github.com/golang/go/issues/11332 - it will be in Go 1.10
On Fri, Oct 27, 2017 at 11:07 AM, Michał Łowicki wrote:
> Hi,
>
> It looks that currently only either http or socks5 are supported (
> https://golang.org/pkg/net/http/):
>
> // The proxy type is determined by the URL scheme. "
It's the client which does the redirect, it's up to it to accept your
request, most will not accept redirects with POST method, for obvious
security reason.
Le samedi 28 octobre 2017 21:12:16 UTC+2, Hui Kang a écrit :
>
> Hi,
> I have a question about sending POST request through the http.Redire
Ø I don't think it needs to be uniformly fair. It just needs to prevent
starvation of a channel for infinity. Any proof would have progress covered if
we pick every channel once in a while, even under a heavily unfair weighting.
You have to balance out the overhead of rolling a fair dice and th
On Saturday, October 28, 2017 at 4:56:42 PM UTC-4, T L wrote:
>
> In my opinion, the memory model article should mention that if event A
> happens event B,
> the the statements shown before event A in source code will be executed
> before event B,
> and the statements shown after event A in sou
I don't believe there are any browsers that support doing this.
On Sat, Oct 28, 2017, 3:33 PM Valentin Vidic
wrote:
> On Fri, Oct 27, 2017 at 09:04:25PM -0700, hkang.sun...@gmail.com wrote:
> > I have a question about sending POST request through the http.Redirect
> > function.
> > The following
On Saturday, October 28, 2017 at 4:56:42 PM UTC-4, T L wrote:
>
> In my opinion, the memory model article should mention that if event A
> happens event B,
> the the statements shown before event A in source code will be executed
> before event B,
> and the statements shown after event A in sou
In my opinion, the memory model article should mention that if event A
happens event B,
the the statements shown before event A in source code will be executed
before event B,
and the statements shown after event A in source code will be executed
after event A.
Otherwise the description
"The wri
On Fri, Oct 27, 2017 at 09:04:25PM -0700, hkang.sun...@gmail.com wrote:
> I have a question about sending POST request through the http.Redirect
> function.
> The following is my http handler function. In this function, I get some
> secret data and want to pass the data to the redirectURL.
> I co
Hi,
I have a question about sending POST request through the http.Redirect
function.
The following is my http handler function. In this function, I get some
secret data and want to pass the data to the redirectURL.
I could not use GET with query parameter because the secret data is
explicit as a
The thing is: The memory model *is for academics*. It is for compiler
authors and people working on low-level primitives. As the author of a
regular Go package or Go program, the only sentence from the memory model
that should be of relevance to you, is
If you must read the rest of this document t
I don't think it needs to be uniformly fair. It just needs to prevent
starvation of a channel for infinity. Any proof would have progress covered
if we pick every channel once in a while, even under a heavily unfair
weighting. You have to balance out the overhead of rolling a fair dice and
the spee
Maybe some of my confusions come from the fact that some descriptions in
the Go 1 memory model article are too academic.
And the article also doesn't cover some order guarantees in Go.
On Saturday, October 28, 2017 at 10:38:19 AM UTC-4, Axel Wagner wrote:
>
> You are correct; I was ignoring the s
You are correct; I was ignoring the second edge specified later. So in some
sense, for unbuffered channels, the edge is bidirectional. You still can't
ignore the fact that channel operations create an edge between two and only
two specific goroutines. And your initial wording is an oversimplificati
you could do your unsafe cast to an appropriately-sized byte array and
write that as a single call or use it to access the bytes:
base := *(*[8]byte)(unsafe.Pointer(&doubleThing))
bs[offset+0]=base[0]
bs[offset+1]=base[1]
:
offset+=8
On Fri, Oct 27, 2017 at 10:18 PM, Tamás Gulácsi
wrote:
> Woul
On Saturday, October 28, 2017 at 9:24:56 AM UTC-4, T L wrote:
>
>
>
> On Saturday, October 28, 2017 at 8:45:00 AM UTC-4, Axel Wagner wrote:
>>
>> No. The channel operations do not act like a fence, but like a… channel,
>> through which happens-before relationships can be transported. The crucial
On Saturday, October 28, 2017 at 8:45:00 AM UTC-4, Axel Wagner wrote:
>
> No. The channel operations do not act like a fence, but like a… channel,
> through which happens-before relationships can be transported. The crucial
> point in the example you quoted is, that the channel-communication cr
Here is a scenario: a high traffic site which executes costly operations
(database / filesystem / compute heavy operations). The web server is
running standard go/http/server.
I would like to handle at most 100 requests and the remainder to queue --
all while the client (curl) is waiting. Are t
No. The channel operations do not act like a fence, but like a… channel,
through which happens-before relationships can be transported. The crucial
point in the example you quoted is, that the channel-communication creates
a happens-before relationship between the two goroutines, which then
connect
The first example in the "Channel communication" section, it says
The write to a happens before the send on c, which happens before the
corresponding receive on c completes, which happens before the print.
>From the description, I feel that "the write to a happens before the send
on c" is not c
ok.
Thanks both for the explanations.
On Saturday, October 28, 2017 at 2:06:06 AM UTC-4, Axel Wagner wrote:
>
> On Sat, Oct 28, 2017 at 12:58 AM, T L >
> wrote:
>
>> Aha, if the second gorotuine "go func() { close(ch) }()" is removed from
>> your example,
>> then I can't find any flaw in what yo
27 matches
Mail list logo
