• Content count

  • Joined

  • Last visited

Community Reputation

3,138 Excellent

About CarlZalph

  • Rank


Visited by the Title Fairy
  • Visited by the Title Fairy

Recent Profile Visitors

10,895 profile views

Single Status Update

See all updates by CarlZalph

  1. I've decided it.  I'm going to learn Go as a programming language.

    Installed and things are functional.  Play time.

    1. Show previous comments  7 more
    2. CarlZalph


      Threaded routines are called 'goroutines'.  They aren't necessarily real threads- Go will automatically make them into new threads if it thinks it needs them or keep the routine into a low-use thread that has other routines in it.  This is all abstracted from the programmer, but neat to know.

      Channels are good for goroutines that need to communicate with each other or an overseer.  Channels use '<-' to denote data transference, and always points like this.  (variable) <- (channel) will read from the channel, and (channel) <- (variable) will write to it.  Reading/writing with a channel handles the locking and unlocking of the used data so you don't have to manage it with mutex/semaphore/etc.

      WaitGroups help with keeping all threads managed until they all quit.  You can have several groups for different goroutine bundles inside goroutines flying all over, with you barely having to manage anything other than ensuring the WaitGroup gets its +Add calls and its defer Done calls in the goroutines.

      Signal handling from the OS (SIGINT/SIGTERM) requires that the main function (aka main goroutine) is available for processing.  Which is to say that if you spun other goroutines that don't release their hold on the CPU, then you can lock yourself out- make sure all goroutines give up control every once in a while with a sleep or blocking function.

    3. CarlZalph


      Having a blocked read on a socket get closed by another goroutine will return an error to the reader.  Thanks to the error handling the dev team forced the error string to be "use of closed network connection" for go 1.x.

      This issue was opened in 2012 and "fixed" in 2018 by forcing this restriction to not change this error string value cross platforms.

      In go 2.x this might change to be better, so for now casting 'error' to 'net.OpError' and then calling its 'Err.Error()' to compare to the string literal to check if I closed the socket or not.

      I know not all languages are perfect and some workarounds are needed, so this doesn't phase me too much especially with a newer language.  Just noting things here.

    4. CarlZalph


      Golang has panic + recover.

      It is defined from the developers of go that you should only use panic if a user's input wasn't expected.  For instance, a file parser that reads in a table of integers suddenly hits a string that shouldn't be, the parser should send out a panic to terminate further parsing; the input is no longer valid.

      Recover is to be used inside a defer function to stop a panic from propagating further.  By default a panic goes all the way back to goroutine 'main' and makes the program terminate.  If you recover from a panic then the program continues operation from where it caught the panic.

      It is assumed that if a panic happens then in the recovery phase it should setup things to return an error code back out to the user using the package.  Documents suggest looking at the JSON parser for their recursive panic escape on invalid parsing.

    5. Show next comments  3 more