Robust Server

[vsupalov]

Make the server less carsh-happy (due to badly formatted JSON for example).

[vsupalov]

Access to objects (such as games) from web(socket)handlers should be synchronized (think mutex) to prevent racing conditions.

[lucasb-eyer]

Only if the webserver itself is multithreaded, which is not necessarily the case if it's a select/poll/epoll/kqueue server! (TODO: figure this out)

[vsupalov]

Good point, I was assuming it. There is concurrency in the handler execution, although there is said to be no parallelism (except when GOMAXPROCS is set to > 1). Testing code:

Golang:

package main

import (
   "fmt"
   "net/http"
   "time"
)

func serve(w http.ResponseWriter, r *http.Request) {
   fmt.Fprintln(w, "Hello there!")
   time.Sleep(5 * time.Second)
}

func main() {
   http.HandleFunc("/", serve)
   http.ListenAndServe(":8090", nil)
}

Bash:

 time for i in `seq 1 5`; do; curl localhost:8090&; done

All requests are finished at the same time and not 5 seconds after one another.

[lucasb-eyer]

So, should we just set GOMAXPROCS to 1 at the beginning of main? That might make our life much easier and it's not really the case that anything is computationally heavy and we'd need parallelism anyways, is it?

[vsupalov]

it is usually set to 1 (by convention, not default) already, but this does not solve the concurrency issues. However, the worst effects of not-minding this that I currently see would be: joining an already full game (when 2 dudes try at the same time and the thread execution gods are benevolent), or scoring the same pair of cards in rush more by two different players. I have not looked hard though.

[lucasb-eyer]

Hmm? As I understood it, "concurrent but not parallel" will only let "other" code run when you call something which relinquishes control, such as Select or read/write a chan or Sleep. With this in mind, I don't see the scenarios you're talking about happening. Am I missing/misunderstanding something?

[vsupalov]

I think my wording was off. By concurrent, I mean that the code may be executed interleaved. Assuming a handler does not just 'Sleep', but something like:

   fmt.Println("Hello there")
   time.Sleep((time.Duration)(rand.Int()%1000) * time.Nanosecond)
   fmt.Println("fine sir")
   time.Sleep((time.Duration)(rand.Int()%1000) * time.Nanosecond)
   fmt.Println("how are you")

then the output for two requests can be interleaving ("Hello...", "Hello...", "fine...", "fine...", "how...", "how..."). As the simplest case: if handler code contains some if condition, it can happen that two requests get through the check at once, instead of just one (scoring the same card by two players for example).

I think our concurrency issues can be solved easily, just by mutex-ing all requests that originate in handlers.

[lucasb-eyer]

Yes, I agree, but what I meant to say is that this "context switch" (quoted, it's not really one) will not happen arbitrarily, but only where "sleeping" functions are called, such as the ones I mentioned previously. Thus, if we don't have any call to such a function, no context will be switched. Having said that, I agree that we can just add mutexes to be on the safe side.

[vsupalov]

Oh, I understand now what you meant. Derp, sry. Are you sure that there are no arbitrary "context switches" (does logging count?), but only sensible ones?

[lucasb-eyer]

I'm confident, but I cannot be sure since I'm no go expert. At the end of the day, your "better be safe than sorry" way is... safer :)