Re: [go-nuts] epoll: why write 1 byte to the pipe in netpollBreak() and read up to 16 bytes in netpoll()?

[metronome]

Hi Ian,

Thanks for clarifying, yes it's no harm to leave the code untouched.

On Tuesday, August 15, 2023 at 3:21:57 AM UTC+8 Ian Lance Taylor wrote:

> On Mon, Aug 14, 2023 at 11:28 AM metronome  wrote:
> >
> > >> If several different goroutines decide to wake up the polling
> > >> goroutine before the polling goroutine wakes up, they will each write
> > >> a single byte
> >
> > Wondering, with the introduction of "netpollWakeSig", does it still hold 
> true? Thanks.
>
> Good point, I think you're right. With netpollWakeSig we shouldn't
> expect to see more than a single byte written to the pipe.
>
> Doesn't hurt to try to read more bytes, though.
>
> Ian
>
> > On Tuesday, July 11, 2023 at 9:00:36 AM UTC+8 Ian Lance Taylor wrote:
> >>
> >> On Mon, Jul 10, 2023 at 6:10 AM shaouai  wrote:
> >> >
> >> > In the implementation of the Go netpoller, `netpollBreak()` attempts 
> to write 1 byte to `netpollBreakWr`, whereas `netpoll()` reads up to 16 
> bytes from `netpollBreakRd`, why 16 bytes rather than 1 byte?
> >> >
> >> > write up to 1 byte: 
> https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/runtime/netpoll_epoll.go;l=77;drc=c7cc2b94c63af610a29b1b48cfbfb87cb8abf05b
> >> >
> >> > read up to 16 bytes: 
> https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/runtime/netpoll_epoll.go;l=146;drc=c7cc2b94c63af610a29b1b48cfbfb87cb8abf05b
> >>
> >> A single byte will wake up a goroutine sleeping in netpoll, so there
> >> is no reason to write more than one byte.
> >>
> >> If several different goroutines decide to wake up the polling
> >> goroutine before the polling goroutine wakes up, they will each write
> >> a single byte, and they will all be satisfied by a single wakeup.
> >> And, if we don't read all those bytes, there will still be bytes in
> >> the pipe and we'll wake up the next time around the poll loop even if
> >> we don't have to. So we try to read all of their wakeup bytes at
> >> once. The number 16 is arbitrary, based on the assumption that it's
> >> not all that likely that more than 16 goroutines will try to wake up
> >> the poller simultaneously.
> >>
> >> Ian
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/8a3ae80e-1e78-441d-8c9a-c99e94e3c2c9n%40googlegroups.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/6a42744a-6c3f-4039-99f2-2f6e993fad52n%40googlegroups.com.

[go-nuts] Re: slog.GroupValue could potentially not make a new slice

[Diego Augusto Molina]

Sorry, just thought it could also use clear to start getting accostumed :)


// GroupValue returns a new Value for a list of Attrs. 
// The caller must not subsequently mutate the argument slice. 
func GroupValue(as ...Attr) Value { 
// Remove empty groups.
// It is simpler overall to do this at construction than
// to check each Group recursively for emptiness.
var write int
for read := range as {
if !as[read].isEmptyGroup() {
if read != write {
as[write] = as[read]
}
write++
}
}
clear(as[write:]) // no need to keep a reference to the string Key
as = as[:write]
return Value{num: uint64(len(as)), any: groupptr(unsage.SliceData(as))}
}

On Monday, 14 August 2023 at 22:06:57 UTC-3 Diego Augusto Molina wrote:

> Hello everyone, thank you for reading. I'm looking at the code of 
> slog.GroupValue (
> https://cs.opensource.google/go/go/+/refs/tags/go1.21.0:src/log/slog/value.go;l=171)
>  
> and was wondering if we could benefit from reusing the same slice like this:
>
> 
> // GroupValue returns a new Value for a list of Attrs. 
> // The caller must not subsequently mutate the argument slice. 
> func GroupValue(as ...Attr) Value { 
> // Remove empty groups.
> // It is simpler overall to do this at construction than
> // to check each Group recursively for emptiness.
> var write int
> for read := range as {
> if as[read].isEmptyGroup() {
> as[read] = Attr{} // no need to keep a reference to the 
> string Key
> } else {
> if read != write {
> as[write] = as[read]
> }
> write++
> }
> }
> as = as[:write]
> return Value{num: uint64(len(as)), any: groupptr(unsage.SliceData(as))}
> }
> 
>
> This, considering that the documentation of the func already states that 
> the user must not mutate the argument slice, so not only the elements but 
> the whole slice could be reused.
> In the case of having lots of attributes with empty group elements, then 
> the stored slice will be unnecessarily larger by that number of Attr 
> elements, but I wonder if that would be negligible, probably an edge case 
> of misuse.
>
> Kind regards.
>

-- 
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/71b83821-b6e2-4ed0-9d36-a97ed1dba290n%40googlegroups.com.

[go-nuts] slog.GroupValue could potentially not make a new slice

[Diego Augusto Molina]

Hello everyone, thank you for reading. I'm looking at the code of 
slog.GroupValue 
(https://cs.opensource.google/go/go/+/refs/tags/go1.21.0:src/log/slog/value.go;l=171)
 
and was wondering if we could benefit from reusing the same slice like this:


// GroupValue returns a new Value for a list of Attrs. 
// The caller must not subsequently mutate the argument slice. 
func GroupValue(as ...Attr) Value { 
// Remove empty groups.
// It is simpler overall to do this at construction than
// to check each Group recursively for emptiness.
var write int
for read := range as {
if as[read].isEmptyGroup() {
as[read] = Attr{} // no need to keep a reference to the string 
Key
} else {
if read != write {
as[write] = as[read]
}
write++
}
}
as = as[:write]
return Value{num: uint64(len(as)), any: groupptr(unsage.SliceData(as))}
}


This, considering that the documentation of the func already states that 
the user must not mutate the argument slice, so not only the elements but 
the whole slice could be reused.
In the case of having lots of attributes with empty group elements, then 
the stored slice will be unnecessarily larger by that number of Attr 
elements, but I wonder if that would be negligible, probably an edge case 
of misuse.

Kind regards.

-- 
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/791c5981-95ea-44e4-a6f9-38cd65842ae4n%40googlegroups.com.

Re: [go-nuts] Generic zero value for compiler optimization

[Diego Augusto Molina]

Thank you very much, that's actually what I was looking for.

On Monday, 14 August 2023 at 13:57:35 UTC-3 Axel Wagner wrote:

> You might be interested in https://github.com/golang/go/issues/61372
>
> On Mon, Aug 14, 2023 at 3:52 PM Diego Augusto Molina <
> diegoaugu...@gmail.com> wrote:
>
>> Hi, thank you for reading. Whenever I need to use a zero value for a 
>> generic type in a func I do something like the following:
>>
>> 
>> func SetZero[T any](pt *T) T {
>> var zeroT T
>> *pt = zeroT
>> }
>> 
>>
>> That's all good, but I wonder how, if possible, it could be proved to the 
>> compiler that zeroT is the zero value for T. That would be to enable 
>> memclr optimization when bulk setting slice or array values to the zero 
>> value of their element type. Currently, as of 1.21, this only works when 
>> the src is a constant holding the zero value of the type. I also tried with 
>> something like *new(T), and it doesn't work either. But proving that the 
>> expression *new(T) in the src is the zero value for the type could 
>> potentially be easier than checking back if a certain variable (e.g. 
>> zeroT in the example) hasn't yet been reassigned or initialized to a 
>> non-zero value.
>> Also, as there's no guarantee of what would T could hold, it could use 
>> memclrHasPointers if that makes sense, which seems like a fare tradeoff 
>> at least for now if we want to play with slices with generic element type.
>> For reference, this is the code I'm trying:
>>
>> 
>> package main
>> // file generic_slice_element_type_memclr.go
>>
>> func clear[T any](s []T) {
>> for i := range s {
>> s[i] = *new(T)
>> }
>> }
>>
>> func main() {
>> clear([]int{1, 2, 3})
>> }
>> 
>>
>> And I'm compiling it with:
>>
>> 
>> $ go version
>> go version go1.21.0 darwin/amd64
>> $ go tool compile -S generic_slice_element_type_memclr.go
>> ...
>> 
>>
>> Kind regards.
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/b8ec1335-911c-42ed-96ce-a4b50153b8c9n%40googlegroups.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/65671596-e4ba-488a-946c-d00f9aef3f20n%40googlegroups.com.

Re: [go-nuts] cgo pam module signal handling

[Chandrasekhar R]

The scenario is:
1) sudo starts and sets up a signal handler for SIGCHLD 
2) pam modules gets loaded
3) Go gets initialized and sets the SA_ONSTACK flag specifically by calling 
rt_sigaction with a pointer to the existing signal handler in *sa_handler *
field*.*
4) Sudo initialized a new signal handler for SIGCHLD
5) After the command is run and SIGCHLD signal is received by a Go created 
thread instead of the parent sudo thread then it goes to the signal handler 
created in step 1.

I believe this is the current set of events happening. I can share a strace 
dump if it would help.

On Monday, August 14, 2023 at 12:17:34 PM UTC-7 Ian Lance Taylor wrote:

> On Mon, Aug 14, 2023 at 12:02 PM Chandrasekhar R  
> wrote:
> >
> > My understanding currently is sudo sets up a signal handler in pre_exec 
> and another signal handler later on which is tied into its main event loop.
> > Go gets initialized when the pre_exec signal handler is used and it adds 
> rt_sigaction(SIGCHLD..) with the SA_ONSTACK flag as mentioned here.
> > Then after the sudo command (echo) gets executed, the SIGCHLD is 
> received by one of the go threads which then runs the pre_exec signal 
> handler which is the old and nonexistent signal handler.
> >
> > My approach is to block the Go threads from receiving the SIGCHLD signal 
> and thus not let the signal to be handled by the old signal handler.
>
> I don't quite understand the scenario you are describing. What
> matters is the signal handler. When Go adds the SA_ONSTACK flag, it
> doesn't change the signal handler. Which thread a signal is delivered
> to does not affect which signal handler gets run.
>
> Ian
>
>
> > On Friday, August 11, 2023 at 10:05:48 PM UTC-7 Ian Lance Taylor wrote:
> >>
> >> On Fri, Aug 11, 2023 at 11:51 AM Chandrasekhar R  
> wrote:
> >> >
> >> > I am planning on using a pam module written in Go (specifically 
> https://github.com/uber/pam-ussh) . When I run a script which calls sudo 
> continuously with an echo command, I am noticing zombie/defunct processes 
> starting to pop up.
> >> >
> >> > On doing strace, I noticed that the SIGCHLD gets delivered to one of 
> the threads created when Go gets initialized (i.e. the shared object gets 
> loaded).
> >> >
> >> > I tried to add one level of indirection by having a separate C code 
> which creates a new thread, sets the signal mask to block SIGCHLD and then 
> use dlopen to open the shared object created using cgo. I am still facing 
> the same issue, is there any pointer on how to fix this issue? I think this 
> would be a wide issue across all PAM modules written using cgo.
> >>
> >> As far as I know the specific thread that receives a SIGCHLD signal is
> >> fairly random. What matters is not the thread that receives the
> >> signal, but the signal handler that is installed. Signal handlers are
> >> process-wide. What signal handler is running when you get a SIGCHLD?
> >> What signal handler do you expect to run?
> >>
> >> Ian
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/7b395394-da12-4b19-9e07-5c8f7e91dcabn%40googlegroups.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/216fb89f-ba9c-41e6-ba90-485b9174a0a5n%40googlegroups.com.

Re: [go-nuts] I need confirmation about whether I'm in front of a linter false positive.

[David Finkel]

On Mon, Aug 14, 2023 at 4:54 PM Pablo Caballero  wrote:

> I started working on a Golang project (from my work). The following
> pattern makes the company configured linter to complain with:
> sloppyReassign: re-assignment to `err` can be replaced with `err :=
> myFunc2()` (gocritic)
>
> func myFunc() error {
> ...
> blah, err := getBlah()
> if err != nil {
> return err
> }
> ...
> if err = myFunc2; err != nil {
> return err
> }
> ...
> }
>
> What bothers me the most is the fact that if I listen to the linter and
> change the code according to its suggestion I get another complaint saying
> that I should use the if short version.
>
> Yes, I have found silenced sloppyReassign following this pattern.
>
> What do you think? What linter complaint should I mute? I don't like the
> idea of a code base polluted with instructions to tell the linter to shut
> up. Do you think I should suggest stopping using linters? :)
>
My recommendation is to stop re-using the "err" variable.
I eliminated missed if err != nil checks in my codebases by using unique
names for my error-typed variables. (and reserving the "err" itself for
innermost scopes -- short if statements like the second case you have there)


>
> Thank you!
>
> --
> 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/CAPxFe-utkjMEVrc3DtTR5rmsiEuK8ZLvA6d228PjnroaxRtBkw%40mail.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/CANrC0Bj5Q6N6otD0QS1i3JFqB9EzPNwYbmTrDOW6PRGxX0Fr8g%40mail.gmail.com.

[go-nuts] I need confirmation about whether I'm in front of a linter false positive.

[Pablo Caballero]

I started working on a Golang project (from my work). The following pattern
makes the company configured linter to complain with:
sloppyReassign: re-assignment to `err` can be replaced with `err :=
myFunc2()` (gocritic)

func myFunc() error {
...
blah, err := getBlah()
if err != nil {
return err
}
...
if err = myFunc2; err != nil {
return err
}
...
}

What bothers me the most is the fact that if I listen to the linter and
change the code according to its suggestion I get another complaint saying
that I should use the if short version.

Yes, I have found silenced sloppyReassign following this pattern.

What do you think? What linter complaint should I mute? I don't like the
idea of a code base polluted with instructions to tell the linter to shut
up. Do you think I should suggest stopping using linters? :)

Thank you!

-- 
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/CAPxFe-utkjMEVrc3DtTR5rmsiEuK8ZLvA6d228PjnroaxRtBkw%40mail.gmail.com.

Re: [go-nuts] epoll: why write 1 byte to the pipe in netpollBreak() and read up to 16 bytes in netpoll()?

[Ian Lance Taylor]

On Mon, Aug 14, 2023 at 11:28 AM metronome  wrote:
>
> >> If several different goroutines decide to wake up the polling
> >> goroutine before the polling goroutine wakes up, they will each write
> >> a single byte
>
> Wondering, with the introduction of "netpollWakeSig", does it still hold 
> true? Thanks.

Good point, I think you're right.  With netpollWakeSig we shouldn't
expect to see more than a single byte written to the pipe.

Doesn't hurt to try to read more bytes, though.

Ian

> On Tuesday, July 11, 2023 at 9:00:36 AM UTC+8 Ian Lance Taylor wrote:
>>
>> On Mon, Jul 10, 2023 at 6:10 AM shaouai  wrote:
>> >
>> > In the implementation of the Go netpoller, `netpollBreak()` attempts to 
>> > write 1 byte to `netpollBreakWr`, whereas `netpoll()` reads up to 16 bytes 
>> > from `netpollBreakRd`, why 16 bytes rather than 1 byte?
>> >
>> > write up to 1 byte: 
>> > https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/runtime/netpoll_epoll.go;l=77;drc=c7cc2b94c63af610a29b1b48cfbfb87cb8abf05b
>> >
>> > read up to 16 bytes: 
>> > https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/runtime/netpoll_epoll.go;l=146;drc=c7cc2b94c63af610a29b1b48cfbfb87cb8abf05b
>>
>> A single byte will wake up a goroutine sleeping in netpoll, so there
>> is no reason to write more than one byte.
>>
>> If several different goroutines decide to wake up the polling
>> goroutine before the polling goroutine wakes up, they will each write
>> a single byte, and they will all be satisfied by a single wakeup.
>> And, if we don't read all those bytes, there will still be bytes in
>> the pipe and we'll wake up the next time around the poll loop even if
>> we don't have to. So we try to read all of their wakeup bytes at
>> once. The number 16 is arbitrary, based on the assumption that it's
>> not all that likely that more than 16 goroutines will try to wake up
>> the poller simultaneously.
>>
>> Ian
>
> --
> 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/8a3ae80e-1e78-441d-8c9a-c99e94e3c2c9n%40googlegroups.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/CAOyqgcV_NZfFCG8wkcKd%3DGmev-Vsi4mTD4ECdh%3DRdeVRDyWAeg%40mail.gmail.com.

Re: [go-nuts] cgo pam module signal handling

[Ian Lance Taylor]

On Mon, Aug 14, 2023 at 12:02 PM Chandrasekhar R  wrote:
>
> My understanding currently is sudo sets up a signal handler in pre_exec and 
> another signal handler later on which is tied into its main event loop.
> Go gets initialized when the pre_exec signal handler is used and it adds 
> rt_sigaction(SIGCHLD..) with the SA_ONSTACK flag as mentioned here.
> Then after the sudo command (echo) gets executed, the SIGCHLD is received by 
> one of the go threads which then runs the pre_exec signal handler which is 
> the old and nonexistent signal handler.
>
> My approach is to block the Go threads from receiving the SIGCHLD signal and 
> thus not let the signal to be handled by the old signal handler.

I don't quite understand the scenario you are describing.  What
matters is the signal handler.  When Go adds the SA_ONSTACK flag, it
doesn't change the signal handler.  Which thread a signal is delivered
to does not affect which signal handler gets run.

Ian


> On Friday, August 11, 2023 at 10:05:48 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Fri, Aug 11, 2023 at 11:51 AM Chandrasekhar R  wrote:
>> >
>> > I am planning on using a pam module written in Go (specifically 
>> > https://github.com/uber/pam-ussh) . When I run a script which calls sudo 
>> > continuously with an echo command, I am noticing zombie/defunct processes 
>> > starting to pop up.
>> >
>> > On doing strace, I noticed that the SIGCHLD gets delivered to one of the 
>> > threads created when Go gets initialized (i.e. the shared object gets 
>> > loaded).
>> >
>> > I tried to add one level of indirection by having a separate C code which 
>> > creates a new thread, sets the signal mask to block SIGCHLD and then use 
>> > dlopen to open the shared object created using cgo. I am still facing the 
>> > same issue, is there any pointer on how to fix this issue? I think this 
>> > would be a wide issue across all PAM modules written using cgo.
>>
>> As far as I know the specific thread that receives a SIGCHLD signal is
>> fairly random. What matters is not the thread that receives the
>> signal, but the signal handler that is installed. Signal handlers are
>> process-wide. What signal handler is running when you get a SIGCHLD?
>> What signal handler do you expect to run?
>>
>> Ian
>
> --
> 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/7b395394-da12-4b19-9e07-5c8f7e91dcabn%40googlegroups.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/CAOyqgcWhtpjyXALJoMFVjVWkfA4kntsxjKbK-LJxoSzJ9z%2BLAw%40mail.gmail.com.

Re: [go-nuts] cgo pam module signal handling

[Chandrasekhar R]

My understanding currently is sudo sets up a signal handler in pre_exec and 
another signal handler later on which is tied into its main event loop.
Go gets initialized when the pre_exec signal handler is used and it adds 
rt_sigaction(SIGCHLD..) with the SA_ONSTACK flag as mentioned here 
. 
Then after the sudo command (echo) gets executed, the SIGCHLD is received 
by one of the go threads which then runs the pre_exec signal handler which 
is the old and nonexistent signal handler.

My approach is to block the Go threads from receiving the SIGCHLD signal 
and thus not let the signal to be handled by the old signal handler.

On Friday, August 11, 2023 at 10:05:48 PM UTC-7 Ian Lance Taylor wrote:

> On Fri, Aug 11, 2023 at 11:51 AM Chandrasekhar R  
> wrote:
> >
> > I am planning on using a pam module written in Go (specifically 
> https://github.com/uber/pam-ussh) . When I run a script which calls sudo 
> continuously with an echo command, I am noticing zombie/defunct processes 
> starting to pop up.
> >
> > On doing strace, I noticed that the SIGCHLD gets delivered to one of the 
> threads created when Go gets initialized (i.e. the shared object gets 
> loaded).
> >
> > I tried to add one level of indirection by having a separate C code 
> which creates a new thread, sets the signal mask to block SIGCHLD and then 
> use dlopen to open the shared object created using cgo. I am still facing 
> the same issue, is there any pointer on how to fix this issue? I think this 
> would be a wide issue across all PAM modules written using cgo.
>
> As far as I know the specific thread that receives a SIGCHLD signal is
> fairly random. What matters is not the thread that receives the
> signal, but the signal handler that is installed. Signal handlers are
> process-wide. What signal handler is running when you get a SIGCHLD?
> What signal handler do you expect to run?
>
> Ian
>

-- 
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/7b395394-da12-4b19-9e07-5c8f7e91dcabn%40googlegroups.com.

Re: [go-nuts] epoll: why write 1 byte to the pipe in netpollBreak() and read up to 16 bytes in netpoll()?

[metronome]

>> If several different goroutines decide to wake up the polling
>> goroutine before the polling goroutine wakes up, they will each write
>> a single byte

Wondering, with the introduction of "netpollWakeSig", does it still hold 
true? Thanks.

On Tuesday, July 11, 2023 at 9:00:36 AM UTC+8 Ian Lance Taylor wrote:

> On Mon, Jul 10, 2023 at 6:10 AM shaouai  wrote:
> >
> > In the implementation of the Go netpoller, `netpollBreak()` attempts to 
> write 1 byte to `netpollBreakWr`, whereas `netpoll()` reads up to 16 bytes 
> from `netpollBreakRd`, why 16 bytes rather than 1 byte?
> >
> > write up to 1 byte: 
> https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/runtime/netpoll_epoll.go;l=77;drc=c7cc2b94c63af610a29b1b48cfbfb87cb8abf05b
> >
> > read up to 16 bytes: 
> https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/runtime/netpoll_epoll.go;l=146;drc=c7cc2b94c63af610a29b1b48cfbfb87cb8abf05b
>
> A single byte will wake up a goroutine sleeping in netpoll, so there
> is no reason to write more than one byte.
>
> If several different goroutines decide to wake up the polling
> goroutine before the polling goroutine wakes up, they will each write
> a single byte, and they will all be satisfied by a single wakeup.
> And, if we don't read all those bytes, there will still be bytes in
> the pipe and we'll wake up the next time around the poll loop even if
> we don't have to. So we try to read all of their wakeup bytes at
> once. The number 16 is arbitrary, based on the assumption that it's
> not all that likely that more than 16 goroutines will try to wake up
> the poller simultaneously.
>
> Ian
>

-- 
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/8a3ae80e-1e78-441d-8c9a-c99e94e3c2c9n%40googlegroups.com.

Re: [go-nuts] Generic zero value for compiler optimization

['Axel Wagner' via golang-nuts]

You might be interested in https://github.com/golang/go/issues/61372

On Mon, Aug 14, 2023 at 3:52 PM Diego Augusto Molina <
diegoaugustomol...@gmail.com> wrote:

> Hi, thank you for reading. Whenever I need to use a zero value for a
> generic type in a func I do something like the following:
>
> 
> func SetZero[T any](pt *T) T {
> var zeroT T
> *pt = zeroT
> }
> 
>
> That's all good, but I wonder how, if possible, it could be proved to the
> compiler that zeroT is the zero value for T. That would be to enable
> memclr optimization when bulk setting slice or array values to the zero
> value of their element type. Currently, as of 1.21, this only works when
> the src is a constant holding the zero value of the type. I also tried with
> something like *new(T), and it doesn't work either. But proving that the
> expression *new(T) in the src is the zero value for the type could
> potentially be easier than checking back if a certain variable (e.g. zeroT
> in the example) hasn't yet been reassigned or initialized to a non-zero
> value.
> Also, as there's no guarantee of what would T could hold, it could use
> memclrHasPointers if that makes sense, which seems like a fare tradeoff
> at least for now if we want to play with slices with generic element type.
> For reference, this is the code I'm trying:
>
> 
> package main
> // file generic_slice_element_type_memclr.go
>
> func clear[T any](s []T) {
> for i := range s {
> s[i] = *new(T)
> }
> }
>
> func main() {
> clear([]int{1, 2, 3})
> }
> 
>
> And I'm compiling it with:
>
> 
> $ go version
> go version go1.21.0 darwin/amd64
> $ go tool compile -S generic_slice_element_type_memclr.go
> ...
> 
>
> Kind regards.
>
> --
> 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/b8ec1335-911c-42ed-96ce-a4b50153b8c9n%40googlegroups.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/CAEkBMfF%2Bwu5zqF6_PQMDdDXKQEuVjH5ZDsQYqPXwXqgpmQ3JCQ%40mail.gmail.com.

[go-nuts] Generic zero value for compiler optimization

[Diego Augusto Molina]

Hi, thank you for reading. Whenever I need to use a zero value for a 
generic type in a func I do something like the following:


func SetZero[T any](pt *T) T {
var zeroT T
*pt = zeroT
}


That's all good, but I wonder how, if possible, it could be proved to the 
compiler that zeroT is the zero value for T. That would be to enable memclr 
optimization when bulk setting slice or array values to the zero value of 
their element type. Currently, as of 1.21, this only works when the src is 
a constant holding the zero value of the type. I also tried with something 
like *new(T), and it doesn't work either. But proving that the expression 
*new(T) in the src is the zero value for the type could potentially be 
easier than checking back if a certain variable (e.g. zeroT in the example) 
hasn't yet been reassigned or initialized to a non-zero value.
Also, as there's no guarantee of what would T could hold, it could use 
memclrHasPointers if that makes sense, which seems like a fare tradeoff at 
least for now if we want to play with slices with generic element type.
For reference, this is the code I'm trying:


package main
// file generic_slice_element_type_memclr.go

func clear[T any](s []T) {
for i := range s {
s[i] = *new(T)
}
}

func main() {
clear([]int{1, 2, 3})
}


And I'm compiling it with:


$ go version
go version go1.21.0 darwin/amd64
$ go tool compile -S generic_slice_element_type_memclr.go
...


Kind regards.

-- 
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/b8ec1335-911c-42ed-96ce-a4b50153b8c9n%40googlegroups.com.

Re: [go-nuts] Re: slog's use of runtime.Callers() with a skip

['Shaun Crampton' via golang-nuts]

>
> Do you have any evidence to the contrary?


Only that when Go 1.12 dropped, our similar function stopped working and
that reducing the skip seemed to do the trick.

The symptom was that our function would see an assembly file as the caller,
which I interpreted to mean that we'd skipped too far.  It only happened in
goroutines with short stacks and I put it down to inlining.

Quite possible that the "fix" I made was mistaken, or that runtime.Callers
has been updated/fixed since then.

In case you want to stare at my fix, here is the diff:
https://github.com/projectcalico/libcalico-go/commit/1f1ababe294be198148c4232ef6c0344898d3b31#diff-7ab3329a79d456fe0d1747bba7344ac61e839f9097ae65d09b36f3c11ea13fbdL153


Looking back, I see three changes in that "fix":

   - Change to skip from 6 to 1 (and increase pcs buffer size accordingly).
   - Reslice pcs to the valid portion, looks like we missed that before;
   possible this was the "real" fix?
   - Change the list of file names that we skip.

We were already using CallersFrames before the fix.

The Go runtime does the right thing.
>

It does seem to in my local tests with up-to-date Go; i tried some toy
examples and checked that functions really were being inlined.

-- 
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/CAMhR0U1DtH_HLPFDO%2BRPT1xU0SxynoP_63uNE%2BzJ%2BES9wX%3D2Xg%40mail.gmail.com.

[go-nuts] Re: What does `shallow clone` mean?

[Brian Candler]

On Friday, 11 August 2023 at 17:56:01 UTC+1 Shinya Sakae wrote:

I often hear the term `shallow copy', but I don't know what `shallow clone` 
means.


Don't worry: they are the same thing.

When cloning a map, the keys and values are set using ordinary assignment, 
as the description says.  It means there is no recursive cloning of nested 
structures.

For example: assignment of a map ends up with two values pointing at the 
*same* data structure:
https://go.dev/play/p/NzCII0hy92R
(that's why clone is needed in the first place: so you can 
add/update/delete to the clone, without affecting the source map)

Therefore, if you have an outer map containing inner maps as values, and 
you clone the outer map, the clone will still refer to the same inner maps.

-- 
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/27dac806-a1a8-42bd-bbe1-06d21a796eedn%40googlegroups.com.