Comment by John_R_S

It seems that of the information presented is wrong. For example:

Go's goroutines are not coroutines. Coroutines are another form of concurrency, which: . shares a stack and scope . uses "split" and "join" . generally is limited to run on the same thread, not in parallel . switches cooperatively, not preemptively NONE of these are true for goroutines. Also: . Goroutines do not have a parent-child relationship. This would limit their usefulness. If you need it, there are 3rd party libraries which encapulsate and add that functionality. . There is currently a proposal to add coroutines to Go. They are lighter than goroutines and are handy in certain cases. . Note: Initially goroutines could be preempted only when making a function call. As of Go v1.14, about 4 years ago, full preemption was added.

Synchronization is possible many ways: . "channels" . "select" statement . mutexes, semaphores, and all the common atomic operators. Check the "sync" lib. . Go can certainly use the above techniques based on "real time". Ex: Ticker in the "time" lib.

Go doesn't have "exceptions". It has always had "panics", which are almost the same. . Go philosophy is to handle errors where they occur. . Panics are used by the compiler for non-recoverable runtime errors. . Users can generate panics too, if they choose to. . Panics can be trapped by any function in the call path by using "recover". . Recover, besides executing whatever it cares to, can allow the panic to continue upward or cancel it. . So you can kludge a general exception handler, but it's generally best not to.

Go doesn't use an "event loop" to schedule goroutines. . It does schedule goroutines, but based on multiple criteria. . Scheduling is done independently for each process (fiber).

Having to worry about multiple goroutines trying to close the same file is generally a red flag for poorly structured code. Regardless, there are PLENTY of ways to solve it. Here's two: . Use a synchronized variable to save the open/closed state. . Use a channel for anyone to submit a close request. The receiver, which runs in its own goroutine, can track the open/closed state and act accordingly.

UnixODBC: Perhaps I missed it, but I don't see where it is used in Go itself or in the standard library. I see many SQL interfaces, none of which mention UnixOBDC.

Cancelling a "task": Indeed, Go itself gives no way for one goroutine to cancel another. But setting that up is very easy. You would use a channel or a shared variable to signal the task you wish to cancel. It would have to look for the signal, of course. Also, there are 3rd party libraries which can do this for you. And yes, you could put this feature in a panic (exception) handler, too.