Hi Marvin,
Thanks for your response.
"Do you mean "log/syslog" from the standard library? What does
initialize do?"
>>I have installed syslog-ng parser on my Linux box and I am planning you
use syslog-ng parser and wanted to initialise it's engine for parsing the
data.
so initialise() method in my Go code calls C code that is wrapper around
syslog-ng C header files.So ,I am making use of cgo
*Following is my Go code:*
func (obj Syslogparser) initialise{
X := C.CString(obj.X)
defer C.free(unsafe.Pointer(X))
Y := C.CString(obj.Y)
defer C.free(unsafe.Pointer(Y))
C.initialize_engine(X, Y,
(C.key_value_cb)(unsafe.Pointer(C.callOnMeGo_cgo)));
}
*And following is my C method 'initialize_engine':*
int initialize_engine(const gchar* X, const gchar* Y, key_value_cb cb) //
cb is callback function
{
// does some operation for initialising the engine of syslog-ng parser
return 0;
}
1)I want two instances of syslog-ng engine running on two different
processors.How can I achieve this?
2)I made the following change :
func main {
var obj1 Syslogparser = initalize() // This initialises syslog-ng engine
var obj2 Syslogparser // Not a package-level variable
obj1.ParseMessage(program,msg)// this will parse the data and get the result
if result["Z"] == "unknown"{ // On the basis of this result I want to
initialise a new engine
go func() {
opts := Syslog{}
obj2 = initalize()
obj2.ReloadPatternDB(opts)
obj2.ParseMessage(program, msg)
}()
}
}
Will this initialise two different syslog-ng engines for me ?
3)I understand goroutines are not OS threads and they just run on OS
threads.Can we extract the process id of the running syslog-ng engines
within the go routine where it spawned the syslog-ng engine ?
Thanks
On Wed, May 8, 2019 at 3:01 AM Marvin Renich <m...@renich.org> wrote:
> * 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.
>
--
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/CALjMrq5eQnfJOv%2BG%2B-YD5R2QMm2Qzj0QEkYeeK3ryui3FZwkOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
