Re: [go-nuts] LockOSThread, switching (Linux kernel) namespaces: what happens to the main thread...?

[Ian Lance Taylor]

On Wed, Jun 1, 2022 at 10:45 AM TheDiveO  wrote:
>
> While exploring more of the proc.go code I noticed that my original question 
> somehow didn't fully reflect what I'm wondering about: what happens in the 
> following situation...? Are all tasks/threads really equal?
>
> a non-main G42 goroutine gets scheduled onto the main thread/leader task, 
> which in Linux represents the whole process. What I called also T0 in the 
> discussion above.
> G42 calls runtime.LockOSThread.
> G42 terminates/ends.
>
> What now? Terminating T0 doesn't look like a great idea at second look: for 
> instance, as I mentioned above, this causes some problems further down the 
> road, such as things in the procfs for this process becoming inacessible.

Can you point to some documentation about this problem, or show a
program where it causes problems.

> Is there a way to trick(?) a non-main goroutine onto T0 as an experiment?

I'm not sure what a "non-main goroutine" is.  All goroutines are
basically equivalent.  Assuming you mean the initial goroutine, you
can lock that to the initial thread by calling runtime.LockOSThread in
an init function.  That should wind up calling the main function with
a goroutine locked to the initial thread.  Then you could, for
example, start a new goroutine and then let the initial goroutine
exit.

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/CAOyqgcVPgMHTHbuZh22SFhu-93Bn2gHn9K%2B3nMnAGDN4VU5GDA%40mail.gmail.com.

Re: [go-nuts] [ANN] Event Horizon - first realease of CQRS/ES library

[Bimal Kaluarachchi]

Hi Max
I am trying to learn to implement eventhorizen  is there possibility  to 
give me little example  of implementation.
existing sample bit complected for as i am still learning this ddd concept.

thanks so much

cheers
Bimal 

On Sunday, 23 November 2014 at 01:27:48 UTC+11 Max Ekman wrote:

> Thanks for the reply!
>
> Good that you like the new version, I implemented it partly to show and 
> test the flexibility of the toolkit. I don't want to debate design 
> patterns, but I think it's perfectly ok to define it as delegation. From 
> the Wikipedia article on the pattern:
>
> "a helper object, known as a *delegate*, is given the responsibility to 
> execute a task for the *delegator*."
>
> http://en.wikipedia.org/wiki/Delegation_pattern
>
> Anyway, regarding the command handler and event bus, I did have them as 
> separate objects before but decided to merge them for now to simplify. I 
> think I will split them apart soon though, I like the other approach better.
>
> Regarding the EventStream I agree with you that []Event could be a bit 
> more idiomatic, I may change that!
>
> I'm also thinking of changing the returned events to be a parameter 
> instead of a return, much like the wonderful http.Handler interface. Lots 
> of inspiration to get from that. I have started using the library in a 
> fairly large project and I will probably change and add a lot when I get 
> real (and different) use cases.
>
> Cheers,
> Max
>
>
>
> --
>
> Max Persson
> Software Engineer
>
> +46 708 710504
> m...@looplab.se
>
> ＞ looplab.se
>
> On 22 nov 2014, at 14:43, egon  wrote:
>
>
>
> On Friday, 21 November 2014 15:45:55 UTC+2, Max Persson wrote:
>>
>> Hi Egon,
>>
>> I have now implemented a new dispatcher and aggregate that uses delegation
>>
>
> It's it's forwarding, not delegation... 
> http://en.wikipedia.org/wiki/Delegation_(programming) 
>
> I do like it more than the reflection based version... I also have 
> experimented with having CommandDispatcher and EventBus separate... that 
> would get rid of 
>
> disp.AddHandler, disp.Dispatch -> disp.Register, disp.Handle
> disp.AddSubscriber, disp.Dispatch -> bus.Listen, bus.Publish
>
> This also means, I am able to minimize the dependencies as well. If 
> something needs only the bus, I'll only use the bus...
>
> Also if you add the type as the last parameter in AddSubscriber / 
> AddHandler then you can use varargs... e.g.
>
> disp.Listen(guestListProjector, InviteCreated{}, InviteAccepted{}, 
> InviteDeclined{})
>
> I like the returning of EventStream in CommandHandling, but maybe there is 
> a better way of doing it. The reason I haven't used that approach is 
> because if you emit multiple events and one of the later events depends on 
> the effects of some previous event inside the aggregate then the returning 
> approach will be more confusing.
>
> Also I would probably simply use []Event instead of EventStream.
>
> PS: I also implemented the guestlist example:
> https://github.com/egonelbre/event/tree/master/example/guestlist
>
> Not a verbatim translation, but demonstrates how I would currently 
> implement it. (I'm still not happy with the Aggregate approach...)
>
> + Egon
>
> to let domain aggregates handle type assertion of commands and events 
>> themselves instead of the slightly "magical" reflection version that I 
>> first implemented. It would be interesting to get your thoughts on the 
>> implementation!
>>
>> See the example here: 
>> https://github.com/looplab/eventhorizon/tree/master/examples/delegation
>>
>> Cheers,
>> Max
>>
>> On Tuesday, November 18, 2014 11:32:32 AM UTC+1, egon wrote:
>>>
>>> In the example create a package called "invite" then you can name the 
>>> events/lists as
>>>
>>> invite.Info
>>> invite.Projector
>>>
>>> invite.Created
>>> invite.Accepted
>>> invite.Declined
>>>
>>> Regarding the different packages... I think you went too far with the 
>>> flattening :)
>>> As a general tip, if you have 3 or more parts for your interface/struct 
>>> name then you should structure them better.
>>>
>>> I didn't yet intend to upload my approach, but... 
>>> https://github.com/egonelbre/event
>>> I'm not convinced that the aggregate approach as in most CQRS examples 
>>> is good enough for Go.
>>>
>>> With my approach when implementing some aggregate you would do it:
>>>
>>> package thing
>>>
>>> type Aggregate struct {
>>> event.Aggregate
>>> }
>>>
>>> func (thing *Aggregate) Apply(e event.Event) {
>>> thing.Record(e)
>>>
>>> switch e := e.(type) {
>>> case Created: ...
>>>
>>> // and methods
>>> func (thing *Aggregate) Append(value string){
>>> thing.Apply(Appended{value})
>>> }
>>>
>>> The repository would look like:
>>>
>>> package thing
>>>
>>> type Repository struct {
>>> event.Store
>>> }
>>>
>>> func (repo *Repository) Create() *Aggregate {
>>> ep := {}
>>> ep.Id = event.GenerateId()
>>> return ep
>>> }
>>>
>>> func (repo *Repository) ById(id event.AggregateId) (thing *Aggregate, ok 
>>> bool) {
>>> events, ok := 

Re: [go-nuts] [security] Go 1.18.3 and Go 1.17.11 are released

[Dmitri Shuralyov]

Hi Jakob,

The go-gettable golang.org/dl/go1.18.3 command is published and might take 
a moment to propagate.
You can either try again in a short while, or do something like 'go install 
golang.org/dl/go1.18.3@HEAD'.
(The '@HEAD' suffix is one of the ways to explicitly request that 
particular git revision.)

For questions about the Docker images published 
at https://hub.docker.com/_/golang, you'll want to
contact their maintainers linked at the top of the quick reference section. 
It's reasonable to expect
they'll show up soon now that this Go release is published.

Thanks,
Dmitri

On Wednesday, June 1, 2022 at 5:12:53 PM UTC-4 ja...@kastelo.net wrote:

> On 1 Jun 2022, at 22:58, Dmitri Shuralyov  wrote:
>
>
> Hello gophers,
>
> We have just released Go versions 1.18.3 and 1.17.11, minor point releases.
>
> These minor releases include 4 security fixes following the security 
> policy :
>
>
> Hi Dmitry,
>
> Thanks for this and the notification. However, there does not appear to 
> exist a golang:1.18.3 Docker image, or a go-gettable 
> golang.org/dl/go1.18.3 yet. Are those part of the release, do you know 
> when they will be available?
>
> Best regards,
> Jakob
>
>

-- 
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/f9c9049a-b919-4d74-b943-8aa12332aab9n%40googlegroups.com.

Re: [go-nuts] [security] Go 1.18.3 and Go 1.17.11 are released

[Jakob Borg]

On 1 Jun 2022, at 22:58, Dmitri Shuralyov 
mailto:dmits...@golang.org>> wrote:

Hello gophers,

We have just released Go versions 1.18.3 and 1.17.11, minor point releases.

These minor releases include 4 security fixes following the security 
policy:

Hi Dmitry,

Thanks for this and the notification. However, there does not appear to exist a 
golang:1.18.3 Docker image, or a go-gettable 
golang.org/dl/go1.18.3 yet. Are those part of 
the release, do you know when they will be available?

Best regards,
Jakob

-- 
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/B057D2EF-EC61-4471-9FD9-E454278126D0%40kastelo.net.

[go-nuts] [security] Go 1.18.3 and Go 1.17.11 are released

[Dmitri Shuralyov]

Hello gophers,

We have just released Go versions 1.18.3 and 1.17.11, minor point releases.

These minor releases include 4 security fixes following the security policy
:

   - crypto/rand: rand.Read hangs with extremely large buffers

   On Windows, rand.Read will hang indefinitely if passed a buffer larger
   than 1 << 32 - 1 bytes.

   Thanks to Davis Goodin and Quim Muntal, working at Microsoft on the Go
   toolset, for reporting this issue.

   This is CVE-2022-30634 and Go issue https://go.dev/issue/52561.


   - crypto/tls: session tickets lack random ticket_age_add

   Session tickets generated by crypto/tls did not contain a randomly
   generated ticket_age_add. This allows an attacker that can observe TLS
   handshakes to correlate successive connections by comparing ticket ages
   during session resumption.

   Thanks to GitHub user @nervuri for reporting this.

   This is CVE-2022-30629 and Go issue https://go.dev/issue/52814.


   - os/exec: empty Cmd.Path can result in running unintended binary on
   Windows

   If, on Windows, Cmd.Run, cmd.Start, cmd.Output, or cmd.CombinedOutput
   are executed when Cmd.Path is unset and, in the working directory, there
   are binaries named either "..com" or "..exe", they will be executed.

   Thanks to Chris Darroch (chrisd8...@github.com), brian m. carlson (
   bk2...@github.com), and Mikhail Shcherbakov (https://twitter.com/yu5k3)
   for reporting this.

   This is CVE-2022-30580 and Go issue https://go.dev/issue/52574.


   - path/filepath: Clean(`.\c:`) returns `c:` on Windows

   On Windows, the filepath.Clean function could convert an invalid path to
   a valid, absolute path. For example, Clean(`.\c:`) returned `c:`.

   Thanks to Unrud for reporting this issue.

   This is CVE-2022-29804 and Go issue https://go.dev/issue/52476.

View the release notes for more information:
https://go.dev/doc/devel/release#go1.18.minor

You can download binary and source distributions from the Go web site:
https://go.dev/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.18.3" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Dmitri and Alex for the Go team

-- 
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/CA%2BON-PGhdJhuxrZ_CBmmXyZQTtxZtAT6mV_pi9QMCU%2BNV%2B3zzA%40mail.gmail.com.

[go-nuts] Re: syscall/js: wasm perf question

[atd...@gmail.com]

Seems like it might be a slow handling of wasm in Chrome. Firefox is almost 
twice as fast. There seems to be almost no overhead.

On Tuesday, May 31, 2022 at 3:19:24 PM UTC+2 atd...@gmail.com wrote:

> Hi,
>
> I am trying to optimize some wasm code that runs into the browser.
> So far, the performance is acceptable if not slightly faster than probably 
> unoptimized js DOM manipulation (comparing my implementation of TODOMVC 
> with the vanilla javascript one and react one)
>
> One issue I see is that  triggering event handlers that calls into wasm 
> seem to incur a big overhead penalty (~25ms)
>
> Any idea if this is normal and ways to alleviate it if so? (I haven.t 
> tried using tinyGo yet)
>
> You can find a screenshot of the perf profile here : CDT Perf Profile 
> screenshot 
>
> Many thanks,
>

-- 
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/4f9d1cc7-a5e2-4b68-a0a6-c40534e34689n%40googlegroups.com.

Re: [go-nuts] LockOSThread, switching (Linux kernel) namespaces: what happens to the main thread...?

[TheDiveO]

While exploring more of the proc.go code I noticed that my original 
question somehow didn't fully reflect what I'm wondering about: what 
happens in the following situation...? Are all tasks/threads really equal?

   - a non-main G42 goroutine gets scheduled onto the main thread/leader 
   task, which in Linux represents the whole process. What I called also T0 in 
   the discussion above.
   - G42 calls runtime.LockOSThread.
   - G42 terminates/ends.

What now? Terminating T0 doesn't look like a great idea at second look: for 
instance, as I mentioned above, this causes some problems further down the 
road, such as things in the procfs for this process becoming inacessible.

Is there a way to trick(?) a non-main goroutine onto T0 as an experiment?

On Thursday, May 26, 2022 at 9:54:52 PM UTC+2 TheDiveO wrote:

> Ian, thank you very much! Found it and am now trying to somehow get my 
> head around it!
>
> On Thursday, May 26, 2022 at 9:46:26 PM UTC+2 Ian Lance Taylor wrote:
>
>> On Thu, May 26, 2022 at 12:08 PM TheDiveO  wrote:
>>
>> >
>> > On Thursday, May 26, 2022 at 8:51:49 PM UTC+2 Ian Lance Taylor wrote:
>> >>
>> >> If the scheduler is running on a goroutine locked using
>> >> runtime.LockOSThread and needs to start a new thread, it does so by
>> >> asking a template thread to create it. The template thread doesn't do
>> >> anything other than create new threads, so it should be in a clean
>> >> state.
>> >
>> >
>> > Do you per chance have a link to where I can find the template thread 
>> handling in the runtime scheduler?
>>
>> Search for [tT]emplateThread in $GOROOT/src/runtime/proc.go.
>>
>> 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/059f283c-2c94-4c9c-a4cf-a8c5e35f988fn%40googlegroups.com.

[go-nuts] When compiling into an iOS header file, expect to return **Nullable** String

[张贵广]

If I have the following golang code
```
package sdk
type Person struct { }
func (p *Person) GetName() (string, error) {
return "", errors.New("...")
}
```

When I package it as xcframwork, its header file will probably look like 
this
```
*@interface* SdkPerson : NSObject  {}
// ...
- (NSString* *_Nonnull*)getName:(NSError* *_Nullable** *_Nullable*)error;
@end
```

Then when I call this method in swift I will have to write
```
*var* error: NSError? = *nil*
*let name = person.getName()*
*if let error = error {*
*throw error*
*}*
```

But if we can modify the return value of string to Nullable
`- (NSString* *_Nullable*)getName:(NSError* *_Nullable** *_Nullable*)error;`

Then it will be much easier to write swift code
```
let name = try person.getName()
```
We will write three less lines of code

-- 
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/94c5bdc3-b54d-49a9-a661-b7f15b750c5fn%40googlegroups.com.

Re: [go-nuts] Nil could be the zero value for type variables

['Axel Wagner' via golang-nuts]

On Wed, Jun 1, 2022 at 9:05 AM Brian Candler  wrote:

> On Wednesday, 1 June 2022 at 02:19:43 UTC+1 Ian Lance Taylor wrote:
>
>> We could do that. The main concern is that "nil" is already
>> overloaded, and people new to Go are frequently confused by it. See
>> the FAQ entry https://go.dev/doc/faq#nil_error . Adding more uses of
>> nil will increase the potential for confusion.
>>
>
> I think this is an interesting proposal. If "nil" were to mean "the zero
> value of *any* type" then you can argue it removes a layer of confusion.
> Not only is it the zero value for pointers, interfaces, slices, maps and
> channels, but also for strings, integers, structs, and anything else that
> comes along.
>
> Where confusion might arise is in the operations on nil.  It's already
> weird that nil slices and zero-length slices are distinguishable:
> https://go.dev/play/p/6MVECg4onAk
>
> We'd then end up in the same position with strings, depending on how
> exactly the nil value of a string is defined:
>

I don't think we *could* define it in that way. The zero value of a string
must always be identical to the empty string, so as to not break existing
code. That is, `nil` would become a way to write "", effectively.


> There would be an incentive for Go APIs to treat nil strings and empty
> strings differently (especially in SQL, JSON/YAML etc), and that would
> certainly be a bad thing IMO.
>
> And you might get some other strange stuff, like being able to do
> arithmetic on nil.
>
> a := 3
> b := a + nil   // b := a + 0  ??
> var c float64 = nil + nil   // ???
>

Theoretically, that depends on how this was actually done. Currently, the
pre-declared identifier `nil` is not actually a value, as such. The spec
treats it as a special case for comparisons
 and assignability
, for example.

I think we would have to continue making it a special case in many if not
most aspects. It might be tempting to define `nil` as an untyped constant,
but then we'd have to give it a default type and there does not seem to be
a good option.

I think if we'd a) made the predeclared identifier `nil` assignable to any
type and b) expanded the special case for comparisons to all types, we'd
get the desired effect without allowing arithmetic expressions like these.

That being said, I also don't see a lot of harm in allowing them, if we
make `nil` represent the zero value of any type. It is true that the code
reads strangely, but we don't have to disallow all strange code.

Lastly, with all this in mind: I agree with Ian that overloading `nil`
further is probably not good, even though we could. Most questions about it
come in the form of "That function returns nil, but if I compare to nil
it's false", or "I get a nil-pointer exception, but I checked for nil right
before that" and those definitely wouldn't get any less confusing.


> --
> 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/7292a481-af17-49a3-b887-93ab55c35bcen%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/CAEkBMfGMXVRZCvuQ-RqGXLiib9YJcf3qYgvtyxKDah4fGuA%2BtQ%40mail.gmail.com.

Re: [go-nuts] Nil could be the zero value for type variables

[Brian Candler]

On Wednesday, 1 June 2022 at 02:19:43 UTC+1 Ian Lance Taylor wrote:

> We could do that. The main concern is that "nil" is already 
> overloaded, and people new to Go are frequently confused by it. See 
> the FAQ entry https://go.dev/doc/faq#nil_error . Adding more uses of 
> nil will increase the potential for confusion. 
>

I think this is an interesting proposal. If "nil" were to mean "the zero 
value of *any* type" then you can argue it removes a layer of confusion. 
Not only is it the zero value for pointers, interfaces, slices, maps and 
channels, but also for strings, integers, structs, and anything else that 
comes along.

Where confusion might arise is in the operations on nil.  It's already 
weird that nil slices and zero-length slices are distinguishable:
https://go.dev/play/p/6MVECg4onAk

We'd then end up in the same position with strings, depending on how 
exactly the nil value of a string is defined:

var s2 string
if s2 == nil { ... }  // but this is different to "" ?

There would be an incentive for Go APIs to treat nil strings and empty 
strings differently (especially in SQL, JSON/YAML etc), and that would 
certainly be a bad thing IMO.

And you might get some other strange stuff, like being able to do 
arithmetic on nil.

a := 3
b := a + nil   // b := a + 0  ??
var c float64 = nil + nil   // ???

-- 
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/7292a481-af17-49a3-b887-93ab55c35bcen%40googlegroups.com.