Re: [go-nuts] syscall/js: strange deadlock caused by wasm event handling callback (runtime bug?)

[at diar]

Doesn't seem that this is a known issue. I will try and write a short
reproducer and file an issue.

On Fri, Aug 5, 2022, 11:18 PM atd...@gmail.com  wrote:

> Hi,
>
> I have a little concurrency problem. Seems that my Go-wasm-defined event
> handlers run concurrently instead of synchronously.
>
> Basically, the event handler is called by runtime.handleEvent which calls
> into the syscall/js defined version of it
>
> Link to source
> 
> // handleEvent gets invoked on a call from JavaScript into Go. It calls
> the event handler of the syscall/js package
> // and then parks the handler goroutine to allow other goroutines to run
> before giving execution back to JavaScript.
> // When no other goroutine is awake any more, beforeIdle resumes the
> handler goroutine. Now that the same goroutine
> // is running as was running when the call came in from JavaScript,
> execution can be safely passed back to JavaScript.
> func handleEvent() {
>e := {
>gp: getg(),
>returned: false,
>}
>events = append(events, e)
>*eventHandler() // *
>clearIdleID()
>// wait until all goroutines are idle
>e.returned = true
>gopark(nil, nil, waitReasonZero, traceEvNone, 1)
>events[len(events)-1] = nil
>events = events[:len(events)-1]
>// return execution to JavaScript
>pause(getcallersp() - 16)
> }
>
> In syscall/js, Link to source
> 
> func handleEvent() {
>cb := jsGo.Get("_pendingEvent")
>if cb.IsNull() {
>return
>}
>jsGo.Set("_pendingEvent", Null())
>id := uint32(cb.Get("id").Int())
>if id == 0 { // zero indicates deadlock
>select {}
>}
>funcsMu.Lock()
>f, ok := funcs[id]
>funcsMu.Unlock()
>if !ok {
>Global().Get("console").Call("error", "call to released function")
>return
>}
>this := cb.Get("this")
>argsObj := cb.Get("args")
>args := make([]Value, argsObj.Length())
>for i := range args {
>args[i] = argsObj.Index(i)
>}
>*result := f(this, args) // My callback runs here*
>cb.Set("result", result)
> }
>
>
> Basically, f causes a deadlock because it locks a mutex but never unlocks
> before being called again in response to another JS event.
> If I remove the lock, it's fine but he program should be incorrect as
> event handlers should be run synchronously.
>
> *Tried to instrument the code to display the call stack. You can see
> toward the end that there is an attempt to take a lock while handling the
> focus event that has not been unlocked beforehand while processing the
> click event.*
>
> 2022/08/05 22:24:25 focusTodo-App
> wasm_exec.js:22 2022/08/05 22:24:25 LOCKING
> 
> wasm_exec.js:22 2022/08/05 22:24:25 LOCkED
> --
> wasm_exec.js:22 2022/08/05 22:24:25 6
> wasm_exec.js:22 runtime.Callers
> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.SDEBUG
> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.glob..func2.1
> wasm_exec.js:22 syscall/js.handleEvent
> wasm_exec.js:22 runtime.handleEvent
> wasm_exec.js:22 runtime.goexit
> wasm_exec.js:22 2022/08/05 22:24:25 UNLOCKING
> 
> wasm_exec.js:22 2022/08/05 22:24:25 7
> wasm_exec.js:22 runtime.Callers
> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.SDEBUG
> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.freelock
> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.glob..func2.1
> wasm_exec.js:22 syscall/js.handleEvent
> wasm_exec.js:22 runtime.handleEvent
> wasm_exec.js:22 runtime.goexit
> wasm_exec.js:22 2022/08/05 22:24:25 UNLOCkED
> --
> wasm_exec.js:22 2022/08/05 22:24:32 focusTodo-App
> wasm_exec.js:22 2022/08/05 22:24:32 LOCKING
> 
> wasm_exec.js:22 2022/08/05 22:24:32 LOCkED
> --
> wasm_exec.js:22 2022/08/05 22:24:32 6
> wasm_exec.js:22 runtime.Callers
> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.SDEBUG
> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.glob..func2.1
> wasm_exec.js:22 syscall/js.handleEvent
> wasm_exec.js:22 runtime.handleEvent
> wasm_exec.js:22 runtime.goexit
> wasm_exec.js:22 2022/08/05 22:24:32 UNLOCKING
> 
> wasm_exec.js:22 2022/08/05 22:24:32 7
> wasm_exec.js:22 runtime.Callers
> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.SDEBUG
> wasm_exec.js:22 github.com/atdiar/particleui/drivers/js.freelock
> wasm_exec.js:22 

Re: [go-nuts] Type parameters syntax... Can it be improved?

[at diar]

Yes that too. To differentiate between MinFloat and MinInt for instance.


:)

On Thu, Mar 25, 2021, 8:18 AM Martin Leiser  wrote:

>
>
> Ian Lance Taylor schrieb am Dienstag, 23. März 2021 um 23:22:51 UTC+1:
>
>> On Tue, Mar 23, 2021 at 3:19 PM atd...@gmail.com 
>> wrote:
>> >
>> > Since, we also know the type of v, It would be infered from it.
>> >
>> > There is no variance, no dependent type... Meaning that the type of a
>> Go variable does not change.
>> > So the constraints do not change midway through the program, including
>> type names/definitions.
>> >
>> > It does however require to have something that resemble a type
>> definition beforehand.
>> > A type parameter definition.
>>
>> In some cases it can be inferred.
>
>
> But even if it can be inferred it should be possible to annotate the type
> I do expect,
> to improve local readiblity and compile time error message quality:
> I assume that "x" is later used in a context requiring the type to be
> "int":
>   x := Min(someFunc(foo), someFunc(bar))
> Here i can use:
>   var x int = Min(someFunc(foo), someFunc(bar)))
> but using
>  x := Min[int]( someFunc(foo), someFunc(bar)))
> The three version yield different error message, if the called function
> "someFunc()" return a float instead of the expected int.
>
> But what about cases where it
>> can't? And what if I want to write
>>
>> // IntMin is a function with type func(int, int) int.
>> var IntMin = Min[int]
>>
> ?
>>
>> The constraints don't change midway through a program, but in your
>> example the meaning of T does change.
>>
>>
> hmmm... if all I need throughout my whole package is one binding e.g. to
> "int",
> or to the type parameter "MyParameterType" my function use for themselves
> it may get teadious to
> repeat the [MyParameter] all over the place.
> Type inferences helps, but weakens the quality of error messages.
> So please always allow for a explicit type parameter annotation even if
> inference is possible.
> (And doing so in a more global location may improve simplicity a lot;-)
>
> Martin
>
>> Ian
>>
>>
>> > On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote:
>> >>
>> >> On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com 
>> wrote:
>> >> >
>> >> > Quick question...
>> >> >
>> >> > Why do we need brackets to define a parametered function, struct
>> etc...?
>> >> >
>> >> > Why not change Go kinds to accept either a type (would produce a
>> regular, function, structs, etc) or a new type parameter object that would
>> implement the constraints (would produce a generic function definition)
>> >> >
>> >> > for instance,
>> >> >
>> >> > type parameter T
>> >> >
>> >> > // [...] some way to add constraint to T
>> >> >
>> >> > func Max(v T) T{...}
>> >> >
>> >> > What are the brackets for? Just an idea.
>> >>
>> >> Each call to Max can use a different value for T. We can call
>> >> Max[int] and Max[string]. How would we do that with this notation?
>> >>
>> >> A type parameter really is a parameter to the function. Making it
>> >> syntactically similar to other non-type parameters seems like a good
>> >> idea to me.
>> >>
>> >> 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/5713130f-20c7-4b70-ba8f-2e9be22cb9c9n%40googlegroups.com.
>>
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/x3ZffZXHMyA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/ba6f07e2-f89f-4d59-9f10-e0e2fcea004en%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/CAJcwgVq81_T8_A13o1P_%3D4Tk8WcLgotoZwxxs76Aw_03iZ%2BxSQ%40mail.gmail.com.

Re: [go-nuts] Re: Type parameters syntax... Can it be improved?

[at diar]

Yes, and... (just in case someone else comes across this thread wondering
in the distant future) ,

func(v T) T is not too big a problem but func(v T) R

If the function body has cases, i.e. flow sensitive, that's where the
brackets are mandatory to make the inference more straightforwardly
decidable.

Unfortunately, that's what happens if returns are created by unboxing an
interface for instance. We introduce variance.

It might be solvable/partially solvable via constraint-propagation /
type-flow analysis or we can be wise and just constrain return values to be
of a specific type but then brackets are needed.












On Wed, Mar 24, 2021, 9:28 AM Markus Heukelom 
wrote:

> I agree here that there is a lot of repetition in the function definitions
> of let's say a generic math package:
>
> types Numbers { type float32,float64,  }
>
> func Abs[T Floats](a T) T {}
> func Sin[T Floats](a T) T {}
> func Cos[T Floats](a T) T {}
>
> etc. (50 orso more?)
>
> It feels a bit redundant and "noisy" to the eye. I think in practice, any
> good generic packages will only use maybe one or two type parameters
> constrainsts (interfaces), and likewise most types (functions) will use
> very similar if not the same type parameters lists.
>
> So I tried to come up with a solution similar to yours by predefining T
> which could then be directly. But as Ian illustrated there's issues that
> are not naturally solved. So I agree that the current proposal is simpler
> (with the downside of being a bit "noisier" wrt such a proposal).
>
> Another solution that comes to mind would be to allow to some sort of
> grouping structure:
>
> generic [T Numbers] {
> func Abs(a T) T {}
> func Sin(a T) T {}
> func Cos(a T) T {}
> }
>
> This would give all types within the group the same type parameters list.
> The grouping my also be useful for documentation. Obvious downside is the
> extra level of indentation on package level (although it nicely separates
> the generic types from concrete types, so maybe just getting used to).
> Another downside is the introduction of the "generic" keyword.
>
> -Markus
>
>
> On Tuesday, March 23, 2021 at 10:16:44 PM UTC+1 atd...@gmail.com wrote:
>
>> Quick question...
>>
>> Why do we need brackets to define a parametered function, struct etc...?
>>
>> Why not change Go kinds to accept either a type (would produce a regular,
>> function, structs, etc) or a new type parameter object that would implement
>> the constraints (would produce a generic function definition)
>>
>> for instance,
>>
>> type parameter T
>>
>> // [...]  some way to add constraint to T
>>
>> func Max(v T) T{...}
>>
>> What are the brackets for? Just an idea.
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/x3ZffZXHMyA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/b802e7fe-4f72-4804-8c23-ea55ac4a5de0n%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/CAJcwgVrw5O%2B_%3D9yxg%3DBVr25gXUrGPS6GkxX7mO3TLOiNbxS3qw%40mail.gmail.com.

Re: [go-nuts] sycall/js : does it require build tags? if so whihc ones?

[at diar]

Thanks. I think I figured it out. Apart from the build tags that you have
mentioned, depending on the code editor, the build tool need to be
specified GOOS and GOARCH too.

And some of the old code completion tools do not support the new syscall/js
package.

In my case, using atom.io, I had to launch it using $ GOOS=js GOARCH=wasm
atom

And I have just uninstalled go-plus. Now using gopls based code tips and
completion etc.

On Sun, Jan 24, 2021, 1:22 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Sun, Jan 24, 2021 at 12:57 AM atd...@gmail.com 
> wrote:
>
> > My issue is that I do not know which build constraints I should specify
> for the static analysers to process the code.
>
> Seems like js _and_ wasm: https://golang.org/src/syscall/js/js.go#L5
>

-- 
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/CAJcwgVrA_tuRRAUrAQWbGWqvd-7_KYP54nXMXYmQQxpcJq0E0w%40mail.gmail.com.