Have you tried https://tinygo.org/ ?
On Thursday, 14 January 2021 at 06:02:35 UTC laos...@gmail.com wrote:
> a helloworld net/http will ask for 1GB VSS, I understand VSS is not the
> same as RSS, also did my googling and know golang malloc.go allocates 512GB
> heap for 64bit system and such.
>
a helloworld net/http will ask for 1GB VSS, I understand VSS is not the
same as RSS, also did my googling and know golang malloc.go allocates 512GB
heap for 64bit system and such.
other GC(garbage collection) languages do not preallocate huge size of VSS
and they worked well.
large size VSS do
On Wed, Jan 13, 2021 at 8:31 PM Robert Engels wrote:
> I forgot. But it’s to important to mention that different synchronization
> methods perform differently under contention so what works well for 2 might
> be really poor with 64.
>
Yes, but the ratio of reads to writes is usually more importa
I forgot. But it’s to important to mention that different synchronization
methods perform differently under contention so what works well for 2 might be
really poor with 64.
> On Jan 13, 2021, at 10:04 PM, Kurtis Rader wrote:
>
>
>> On Wed, Jan 13, 2021 at 7:58 PM Robert Engels wrote:
>
>
On Wed, Jan 13, 2021 at 7:58 PM Robert Engels wrote:
> Why limit yourself to two? Use N routines and have each process every N in
> the list.
>
You missed this statement in the original message of this thread:
So the sketch of the go implementation is that I would have three threads
- main, t0
Why limit yourself to two? Use N routines and have each process every N in the
list.
> On Jan 13, 2021, at 7:25 PM, Nikolay Dubina
> wrote:
>
>
> Any primitive in `sync` package will do. I would go for two `RWMutex` each
> for each goroutine, or two unbuffered channels for each gorouitne.
Any primitive in `sync` package will do. I would go for two `RWMutex` each
for each goroutine, or two unbuffered channels for each gorouitne. However,
AFAIK, in Go you can't force start execution of a goroutine. Go will try to
wake up any unblocked goroutine as soon as possible though.
On Thursd
This https://github.com/robaho/go-concurrency-test might help. It has some
relative performance metrics of some sync primitives. In general though Go uses
“fibers” which don’t match up well with busy loops - and the scheduling
overhead can be minimal.
> On Jan 13, 2021, at 6:57 PM, Peter Wilso
Folks
I have code in C which implements a form of discrete event simulator, but
optimised for a clocked system in which most objects accept input on the
positive edge of a simulated clock, do their appropriate internal
computations, and store the result internally. On the negative edge of the
c
On Wed, Jan 13, 2021 at 7:39 AM xie cui wrote:
>
> in linker,
> the code is like this:
>
> func f() {
>g()
> }
>
> func g() {
> f()
> }
> when gen binary code of func f, need func g, and gen g need f,
> how linker deal with this situation, and where is the code?
> is dynrelocsym do this jo
On Wed, Jan 13, 2021 at 6:38 AM Kevin Chadwick wrote:
>
> On 1/13/21 2:09 PM, Axel Wagner wrote:
> > Let me repeat my question: Do you have any concrete reason to assume there
> > is a
> > negative security impact of generics? Feel free to bring that up.
> > Otherwise, I
> > don't see a reason t
There's also this: https://github.com/golang/go/issues/37755 -- just retain
GOPATH mode
Although, now that I've been using modules more, and my various interdependent
packages are more stable, I am more sympathetic to something like #26640
instead of retaining GOPATH. Anyway, having SOME kind
On Wed, Jan 13, 2021 at 12:39 PM Marcus Manning wrote:
>
> Does reflection support generic instantiation?
No. In the current proposal, generic functions and types are not
visible at run time. Only instantiated functions and types are
visible. So there is no way to even name a generic function/
Here's the backstory to mnm, in a draft article not yet published. I'd love
any feedback...
https://mnmnotmail.org/volunteered.html
On Tue, Jan 5, 2021 at 1:31 PM Liam wrote:
>
> The mnm project is building a legitimate email replacement: a client[1], a
> server[2], and a simple protocol[3] bet
Regarding the the section of No parameterized methods in go generics draft:
package p1 // S is a type with a parameterized method Identity. type S
struct{} // Identity is a simple identity method that works for any type.
func (S) Identity[T any](v T) T { return v } package p2 // HasIdentity is
On Wed, Jan 13, 2021 at 3:38 PM Kevin Chadwick wrote:
> I don't and I don't mean to make demands of other peoples time. Though I'm
> sure
> security has been carefully considered and might be fresh in peoples minds.
I don't think it has, because I don't think it needs to be. There is no
reason
Hello gophers,
We plan to issue Go 1.15.7 and Go 1.14.14 on Tuesday, January 19th.
These are minor releases that include security fixes.
Following our policy at https://golang.org/security,
this is the pre-announcement of those releases.
Cheers,
Roland on behalf of the Go team
--
You re
in linker,
the code is like this:
func f() {
g()
}
func g() {
f()
}
when gen binary code of func f, need func g, and gen g need f,
how linker deal with this situation, and where is the code?
is dynrelocsym do this job? it seem that it can deal with circles calls?
--
You received this mes
I covered the DoS. There are multitude of ways to create DoS even in “correct”
code, panics are just one example.
Memory corruption is a different class of security bug because it allows
arbitrary code execution.
> On Jan 13, 2021, at 8:20 AM, Kevin Chadwick wrote:
>
> On 1/13/21 2:06 PM,
On 1/13/21 2:09 PM, Axel Wagner wrote:
> Let me repeat my question: Do you have any concrete reason to assume there is
> a
> negative security impact of generics? Feel free to bring that up. Otherwise, I
> don't see a reason to talk about it in the design doc.
I don't and I don't mean to make dem
On 1/13/21 2:06 PM, Robert Engels wrote:
> A panic is not a security issue. Memory corruption/stack overflow is. In Go
> the latter is accomplished through CGo and unsafe pointers/operations.
>
It isn't as clear cut as that. Panics can be security issues and memory
corruption/stack overflows ca
On Wed, Jan 13, 2021 at 2:59 PM Kevin Chadwick wrote:
> Clearly Go without interfaces, especially an empty interface is safer.
> Perhaps
> Generics reduce that risk via constraints etc.?
>
I understand why you might argue interfaces make the language less safe.
But generics are a mechanism with
A panic is not a security issue. Memory corruption/stack overflow is. In Go the
latter is accomplished through CGo and unsafe pointers/operations.
Continuous panics can be considered a security issue as a DoS attack but IMO at
least there are many ways to generate continuous errors that are sim
On 1/13/21 11:17 AM, Axel Wagner wrote:
> Assuming generics like interfaces, potentially erode type safety.
>
>
> Can you elaborate? Because that statement seems exactly contrary to
> established
> wisdom.
Clearly Go without interfaces, especially an empty interface is safer. Perhaps
Generi
Dnia 2021-01-13, o godz. 07:22:52
Rob Pike napisał(a):
>Also, one must be sure to remove the replace directive before
> releasing the code, which is an easy detail to forget.
I'd humbly summon https://github.com/golang/go/issues/26640 here.
Opened at the modules advent, still it sees no love fro
>
> if `ws.Read` returns after a reasonable timeout, you can perform a
> non-blocking receive on the quit channel to see if it has been
> closed/something has been sent to it:
>
> select {
> case <-quit:
> break
> default:
>
On Wed, Jan 13, 2021 at 11:54 AM Kevin Chadwick wrote:
> I appreciate that generics use will be optional. However I am concerned
> that neither in the design draft nor the proposal issue, that the word
> security nor safety has been used even once.
"Safety" has been mentioned lots of times, in
Hi,
if `ws.Read` returns after a reasonable timeout, you can perform a
non-blocking receive on the quit channel to see if it has been
closed/something has been sent to it:
select {
case <-quit:
break
default:
I have a function that must be executed as a go routine infinitely until a
message comes in a channel. For example:
func readWebSocket(ws *websocket.socket, quit chan bool) {
for {
out, err = ws.Read()
log.Println(out, err)
}
}
Now I call this above function as a goroutine from ma
I appreciate that generics use will be optional. However I am concerned that
neither in the design draft nor the proposal issue, that the word security nor
safety has been used even once.
Assuming generics like interfaces, potentially erode type safety.
Will generics increase the likelihood of
30 matches
Mail list logo
