* Nitish Saboo <nitish.sabo...@gmail.com> [190507 14:07]:
> Thanks Michel for your detailed response.
> I am initialising the syslog engine.
Do you mean "log/syslog" from the standard library? What does
initialize do?
> var obj1 parser = initalize()
> var obj2 parser
> go func() {
> obj2 = initalize()
> }()
You have initialized obj1, then you create a go routine that initializes
obj2. Assuming the initialization step takes a relatively short amount
of time and terminates, and does not itself create another go routine,
obj2 is not "on another go routine" (or thread or CPU or anything else).
It is simply another variable whose value was assigned by a different go
routine, but that go routine terminated immediately after obj2 was given
its value.
Note that obj2 is a variable, not a running function; it is not
associated with a specific go routine, at least not in the sense that
you appear to be thinking. If obj2 is declared at the package level,
than any function in the package can reference it regardless of the go
routine in which that function is running.
> if obj1 engine fails:
> go func() {
> obj2.ReloadPattern(opts)
> }()
>
> My question is, will obj2.ReloadPattern reload the pattern on the second
> syslog-engine , how can I verify that?Because I am not maintaining the
> engine info. I am just having the parser object.
> Will parser object obj2 go and reload the respective syslog engine that was
> initialised by it? I guess yes, but still need clarification on this .
A new go routine will be created (possibly unnecessarily, but you don't
give enough information), and the ReloadPattern method of obj2 will be
invoked in that go routine. When ReloadPattern terminates, the go
routine will also terminate. obj2 is still a package-level variable (or
associated with whatever scope in which it was declared).
> Since I was not able to identify the exact syslog engine, I was trying to
> identify it using the processor.
Since you don't give enough information, I'm going to take some guesses,
which could be completely wrong. I am guessing that you are using the
standard library "log/syslog" package, and you have encapsulated the
result of either NewLogger, New, or Dial from that package in your own
structure which is returned by initialize. Your structure has
additional fields and methods, and some of the methods call appropriate
methods on the value obtained from the syslog package.
I don't know what your structure has or what initialize does, but the
result of one of those functions from syslog is not an "engine" in the
sense of code that runs in a loop waiting for requests to do some work.
The result of those functions from syslog is a variable containing
state. When you invoke a method on one of those results, the method
runs in the current go routine, not the go routine where NewLogger, New,
or Dial was run.
> Can we execute any linux command within goroutine to get some sort of info
> on this ?
You seem to have some misconceptions about Go as a whole. In Java,
which is an object oriented language, you can create a Thread object,
which lets you manipulate a new OS thread from within another, already
existing, thread.
First, Go is not an object oriented language, though you can (and it is
often convenient to) use object oriented paradigms, just like you can
use object oriented paradigms from C.
Second, go routines are not OS threads. Different go routines are not
guaranteed to run on different OS threads, though the Go scheduler is
allowed to use multiple OS threads to run multiple go routines at the
same time. Also, a specific go routine is not guaranteed to remain on a
specific OS thread, unless you use runtime.LockOSThread. However, I
would not recommend that you do so until your understanding of go
routines is much more solid that it appears to be; you are unlikely to
obtain the results you expect.
Third, Go does not natively provide any means to identify specific go
routines. This was an intentional language design. Such identification
is almost never necessary, and in other languages is a frequently abused
feature. Two of the common means in Go for one go routine to provide
information about its own state to another go routine are channels and
sync.WaitGroup, but one go routine cannot "inspect" another without
prior arrangement between the two.
It is unclear what you are trying to accomplish by having two "syslog
engines". I get the vague impression that you want something like "high
reliability" so that at least one "engine" is always running and can
restart the other if the other fails. However, there is no indication
of what might cause one to fail while the rest of your Go program is
still running.
If you are connecting to multiple syslog providers on distinct hosts
using syslog.Dial, and trying to recover from an outage on one of the
remote hosts, you are very likely better off having one log variable
(obj1 from above?) that manages multiple *syslog.Writer values, perhaps
with a select statement. No go routines would necessarily be involved.
Again, this is all wild conjecture based on a dearth of information.
...Marvin
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20190507213138.deg3xrvoj4osdprh%40basil.wdw.
For more options, visit https://groups.google.com/d/optout.
