Hi Michael,
Yes, I want (exactly) two instances of syslog-ng engines running since I
initialised the engine twice.And I guess it is possible only when the
syslog-ng engines are running on two different processors.I might be wrong
here, please correct me if my understanding is not right.
My goal right now is how to verify if two independent syslog-ng engines are
getting initialised or not ?
Once this verification is done, Can we hook instance 'a' to syslog-ng
engine on processor 'a' and instance 'b' to syslog-ng engine on processor
'b'.
I hope I am able to clarify my thinking here.
Thanks
On Thu, May 9, 2019 at 4:01 AM Michael Jones <michael.jo...@gmail.com>
wrote:
> Can you share a little more of your motivation for saying: “I want two
> instances of syslog-ng engine running on two different processors.”
>
> Do you mean (minimum) that you want two independent instances, or
> (maximum) that you want to prove that there are two instances, two physical
> processors, and that at no time does processor “a” execute code on behalf
> of instance “b” and likewise for processor “b” and instance “a”, (or
> something else completely).
>
> This “proof” idea seems very unusual but also seems to be what you want.
> Maybe it is not. That’s why it might be good to share more of your thinking
> and not just the conclusion.
>
> The natural thing in most every situation with modern CPUs, OSs, and non
> hard real-time applications, is just having enough total CPU resources for
> the mix of work and enough independence (concurrency opportunity) in the
> application so that the load can be magically balanced.
>
> If this is not enough for you then you must have special circumstances.
>
> On Wed, May 8, 2019 at 2:47 AM Nitish Saboo <nitish.sabo...@gmail.com>
> wrote:
>
>> 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.call
>> to a C library via cgo
>> 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() //call to a C library via cgo
>> obj2.ReloadPatternDB(opts) //call to a C library via cgo
>> obj2.ParseMessage(program, msg) //call to a C library via cgo
>> }()
>> }
>> }
>>
>> 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/CALjMrq7SbZ_pYWjhy1Xu%3DCC5U4RRonDqufFv%3D9pJ%3D4JC8tZ_CQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CALjMrq7SbZ_pYWjhy1Xu%3DCC5U4RRonDqufFv%3D9pJ%3D4JC8tZ_CQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
>
--
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/CALjMrq7_wexQKfXtjC5SohYsrXYpG3BzQr4%3DuL43E3ih93qBnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
