Go http server

[B Carr]

Neophyte here.

Concept help again, please. This all relates to Go.

http server waiting for requests...

http GET request comes in

... goroutine spins up

handler calls function which may call another function which ultimately services the GET request by providing a response (webpage) then returns.

goroutine spins down ...

http server waiting for requests...

Am I correct in thinking that the unique goroutine is active for the entirety of the connection session? Everything between the "goroutine spins up" and "goroutine

spins down" is handled in the one, single goroutine? That the concurrency is automatic at that point?

To carry the idea further...

Two (or a thousand) requests for the same webpage come in at about the same time. The http server spins up two (or a thousand) goroutines that are all active *and* insulated from each other for the duration of the GET-Response cycle.

Am I good in my thinking so far?

[Burak Serdar]

On Wed, Jul 24, 2019 at 12:37 PM B Carr <buc...@gmail.com> wrote:
>
> Neophyte here.
>
> Concept help again, please. This all relates to Go.
>
>
> http server waiting for requests...
>
> http GET request comes in
>
> ... goroutine spins up

Overall your understanding is correct, with the minor detail that the
server continues waiting right after the gorutine spins up.

>
> handler calls function which may call another function which ultimately services the GET request by providing a response (webpage) then returns.
>
> goroutine spins down ...
>
> http server waiting for requests...
>
>
> Am I correct in thinking that the unique goroutine is active for the entirety of the connection session? Everything between the "goroutine spins up" and "goroutine
> spins down" is handled in the one, single goroutine? That the concurrency is automatic at that point?

If that handler goroutine doesn't start others, then that's correct. I
don't understand what you mean by "concurrency is automatic".

>
> To carry the idea further...
>
> Two (or a thousand) requests for the same webpage come in at about the same time. The http server spins up two (or a thousand) goroutines that are all active *and* insulated from each other for the duration of the GET-Response cycle.
>
> Am I good in my thinking so far?

Correct.

>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ac35f488-e846-418a-888b-2e2ddf0e1992%40googlegroups.com.

[B Carr]

On Wednesday, July 24, 2019 at 1:11:31 PM UTC-6, Burak Serdar wrote:

On Wed, Jul 24, 2019 at 12:37 PM B Carr <buc...@gmail.com> wrote:
>
> Am I correct in thinking that the unique goroutine is active for the entirety of the connection session? Everything between the "goroutine spins up" and "goroutine
> spins down" is handled in the one, single goroutine? That the concurrency is automatic at that point?

If that handler goroutine doesn't start others, then that's correct. I
don't understand what you mean by "concurrency is automatic".

Thank you. What I meant by the concurrency comment is that the http server takes care of allowing multiple, same-webpage sessions to occur simultaneously via goroutines and that I don't have to include any 'go func(...)' lines in my code for that to happen. And I don't have the handler goroutine starting up any others.

I'm mostly interested in the degree of insulation one goroutine has from another. My extensive reading indicates that absent a goroutine intentionally communicating outside of itself (via a channel), that whatever it does (short of making changes to globally accessible resources such as a database or map) can't be seen by other goroutines. Is that a correct assessment?

My basic problem is that I'm coming from a Visual Basic background and unlearning bad programming habits is causing me to stumble a lot. Go is far superior to Visual Basic and I'm having fun converting a VB app into a Go webserver app.

But I'm learning a lot too, and so very much appreciate your evaluations. Thank you.

[Burak Serdar]

On Wed, Jul 24, 2019 at 1:36 PM B Carr <buc...@gmail.com> wrote:
>
>
>
> On Wednesday, July 24, 2019 at 1:11:31 PM UTC-6, Burak Serdar wrote:
>>
>> On Wed, Jul 24, 2019 at 12:37 PM B Carr <buc...@gmail.com> wrote:
>> >
>> > Am I correct in thinking that the unique goroutine is active for the entirety of the connection session? Everything between the "goroutine spins up" and "goroutine
>> > spins down" is handled in the one, single goroutine? That the concurrency is automatic at that point?
>>
>> If that handler goroutine doesn't start others, then that's correct. I
>> don't understand what you mean by "concurrency is automatic".
>
>
> Thank you. What I meant by the concurrency comment is that the http server takes care of allowing multiple, same-webpage sessions to occur simultaneously via goroutines and that I don't have to include any 'go func(...)' lines in my code for that to happen. And I don't have the handler goroutine starting up any others.

Correct.

>
> I'm mostly interested in the degree of insulation one goroutine has from another. My extensive reading indicates that absent a goroutine intentionally communicating outside of itself (via a channel), that whatever it does (short of making changes to globally accessible resources such as a database or map) can't be seen by other goroutines. Is that a correct assessment?

Not precisely. The shared resource doesn't have to be global, but
simply accessible from more than one goroutine.

i:=1
go func() { do something with i } ()
go func() { do something else with i} ()

The variable i is not global but shared between three goroutines (the
two, and the one that spawned the other two). Any modification done to
i by one goroutine has no guarantees to being seen by others unless
there is synchronization.

>
> My basic problem is that I'm coming from a Visual Basic background and unlearning bad programming habits is causing me to stumble a lot. Go is far superior to Visual Basic and I'm having fun converting a VB app into a Go webserver app.
>
> But I'm learning a lot too, and so very much appreciate your evaluations. Thank you.
>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/619fd324-b728-48d9-b4e0-68d42e203645%40googlegroups.com.

[B Carr]

On Wednesday, July 24, 2019 at 2:17:58 PM UTC-6, Burak Serdar wrote:

On Wed, Jul 24, 2019 at 1:36 PM B Carr <buc...@gmail.com> wrote:
>
> I'm mostly interested in the degree of insulation one goroutine has from another. My extensive reading indicates that absent a goroutine intentionally communicating outside of itself (via a channel), that whatever it does (short of making changes to globally accessible resources such as a database or map) can't be seen by other goroutines. Is that a correct assessment?

Not precisely. The shared resource doesn't have to be global, but
simply accessible from more than one goroutine.

i:=1
go func() { do something with i } ()
go func() { do something else with i} ()

The variable i is not global but shared between three goroutines (the
two, and the one that spawned the other two). Any modification done to
i by one goroutine has no guarantees to being seen by others unless
there is synchronization.

Ahhhh, a subtle misunderstanding on my part. Thank you.