Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
in go programing, we always create a go routine like
go func(){}
i want to know whether keyword "go" is an atomic operation, what if create a go routine fail by this operation.
can i monitor a new go routine created success or not?
Or maybe this keyword "go" create a routine that will never fail.
The spec says nothing about failure to create the goroutine or invoke the function, so behavior at this point is up to the implementation and there is no defined way to determine success or failure.
The kinds of errors you would encounter on goroutine creation will be fatal errors (likely due to resource exhaustion), not something that can be caught and handled gracefully. This is similar to the kinds of errors you would encounter on invoking a function.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I am working on an application in Go in which I am using goroutines. Each of which connects to third party servers and collects data which is then processed and used in application.
Just as an example :
for _, apiInfo := range apiInfoList {
go external1.GetResponse(searchReq)
go external2.GetResponse(searchReq)
go external3.GetResponse(searchReq)
}
Now these goroutines are running on single server.
Is it possible to run goroutines on individual servers. ?
In my case can I run it on three different servers?
A goroutine (it's a single word) by its very definition is a light-weight thread of execution inside a single process managed by an operating system's kernel.
Hence the question as stated has no sense: if you want a task to be carried out by a separate process you do not need a goroutine — you need a separate process (no matter whether it is to be run on the same machine or not).
To exchange data between separate processes, you need to use some form of IPC.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
In clojure concurrency, I would like the thread that I spawn kill itself if it take to long to do it's task, similar to what Golang ctx withtimeout provide. how should i do it?
Mind you I dont have any knowledge of java thread.
You can't kill a Java thread cleanly, so people usually write very long-running threads to check a flag occasionally, and keep working only if appropriate.
On the other hand, a thread's client can stop waiting for an answer. If you start the thread with future, you can use the timeout parameter on deref at https://clojure.github.io/clojure/clojure.core-api.html#clojure.core/deref, or check on it with future-done?.
When you have a lot of async stuff going on, the better Go-like algebra in Clojure's core.async library can be helpful (https://clojure.github.io/core.async/) as an alternative to raw Java threads.
never mind, apparently there is something called future and promise..
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
For example, if I update a global variable in one goroutine, then read the variable in another goroutine, can I get the newest value?
Another question is, can "atomic.Load*" and "atomic.Store*" ensure visibility?
Without explicit synchronization between goroutines, there is no guarantee that you will see the latest value of a shared variable. The Go memory model describes this:
https://golang.org/ref/mem
Atomic load/store have memory barriers, and they do guarantee you will see the latest value, though the Go memory model does not explicitly state this.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a little state machine in Java which has an unusual state.
The issue is ABORT ...
The task can have two final states: SUCCESSFUL, and FAILED.
But it would be nice to sometimes ABORT a task while it's in the queue, before it ever gets executed and during execution.
While ABORTED is a final state I don't want to have two (or even N) failed states.
FAILED and ABORTED will then have to be checked for. I could also see other failed states like TIMEOUT.
I guess I could have a generic CAUSE for the failure... which could be a TimeoutException, AbortedException, if I want to check for why it failed. Then I could just look at the cause.
Still not super happy with that either.
Any thoughts?
Understanding your problem only abstractly, here are my thoughts on this state machine.
I think FAILED needs to be a category comprising causes such as ABORTED, TIMEOUT, SEGFAULT, UNKNOWN etc. I don't like FAILED as it seems indicates there was some defect in the program or the environment, but I cannot think of a better antonym for SUCCESSFUL that doesn't convey the same meaning.
If the Java framework specifics are your concern, you could easily have an enum that represents these states without much trouble. You would only be checking for SUCCESSFUL or !SUCCESSFUL, as all non-successful things probably deserve similar handling at some level.
While you could take the Exception route, I do not find it sensible to have an AbortedException, especially if that is not actually an exceptional circumstance. Code that is expected should not trigger exceptions, when possible.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I am reading through the msdn articles about windows synchronization. It is really good & thorough material. At the same time is very time consuming. I am more interested in a quick comprehensive guide on the same topic. Any pointers?
This is a list of the concepts that I use in my native (unmanaged, Win32) application. I've added some relevant function names between parenthesis):
CriticalSection (InitializeCriticalSection, TryEnterCriticalSection, LeaveCriticalSection, ...)
Mutex (CreateMutex, WaitForsingleObject, ReleaseMutex, CloseHandle, ...)
Semaphore (CreateSemaphore, WaitForSingleObject, ReleaseSemaphore, CloseHandle, ...)
Event (CreateEvent, SetEvent, ResetEvent, WaitForSingleObject, CloseHandle, ...)
Besides these you could also use a file to implement locking (e.g. between processes running on different machines):
Simply create the file using CreateFile, use FILE_FLAG_DELETE_ON_CLOSE, and don't specify any of the sharing flags.
If a process already created the file, the CreateFile will fail.
To unlock, close the file using CloseHandle.
This might be a good starting point:
Synchronization Functions: http://msdn.microsoft.com/en-us/library/ms686360%28v=VS.85%29.aspx