Re: [go-nuts] C.malloc of Go type?

[andrey mirtchovski]

also useful if you're dealing with blobs of C memory:

https://utcc.utoronto.ca/~cks/space/blog/programming/GoCGoCompatibleStructs

On Sat, May 19, 2018 at 3:03 PM, Jan Mercl <0xj...@gmail.com> wrote:

>
> On Sat, May 19, 2018 at 10:42 PM Max 
> wrote:
>
> > The question is: is it allowed to take the unsafe.Pointer returned by
> C.malloc() and convert it to a pointer to a Go struct type?
>
> See https://golang.org/pkg/unsafe/#Pointer
> --
>
> -j
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] What is restapiserver.webcache

[asaaveri]

All:

I have a very simple HelloWorld REST API server in go and a corresponding 
Go client.  The objective is to see benchmark -- i.e. what is the most TPS 
a Go server can support.  I used tcpdumo to see the exchanges.  I was 
expecting to see just my restapiserver:8080 but I see some w/ 
restapiserver.webcache.  See below:

What is .webcache?  Is this an artifact of go http server?

2018-05-19 16:53:58.446704 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], 
proto TCP (6), length 52)
10.39.195.205.60731 > restapiserver.webcache: Flags [.], cksum 0x8b1f 
(correct), seq 1249, ack 1633, win 4091, options [nop,nop,TS val 2332993641 
ecr 993529662], length 0
2018-05-19 16:53:58.446794 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], 
proto TCP (6), length 156)
10.39.195.205.60731 > restapiserver.webcache: Flags [P.], cksum 0x7d18 
(correct), seq 1249:1353, ack 1633, win 4096, options [nop,nop,TS val 
2332993641 ecr 993529662], length 104: HTTP, length: 104
GET /HelloWorld HTTP/1.1
Host: restapiserver:8080
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip
2018-05-19 16:53:58.446994 IP (tos 0x0, ttl 64, id 29113, offset 0, flags 
[DF], proto TCP (6), length 188)
restapiserver.webcache > 10.39.195.205.60731: Flags [P.], cksum 0x6319 
(incorrect -> 0x52e6), seq 1633:1769, ack 1353, win 210, options 
[nop,nop,TS val 993529843 ecr 2332993641], length 136: HTTP, length: 136
HTTP/1.1 200 OK
Content-Type: application/json
Date: Sat, 19 May 2018 23:53:58 GMT
Content-Length: 28
{"Greetings":"Hello World"}


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] C.malloc of Go type?

[Jan Mercl]

On Sat, May 19, 2018 at 10:42 PM Max 
wrote:

> The question is: is it allowed to take the unsafe.Pointer returned by
C.malloc() and convert it to a pointer to a Go struct type?

See https://golang.org/pkg/unsafe/#Pointer
-- 

-j

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: C.malloc of Go type?

[Max]

On Saturday, May 19, 2018 at 10:42:12 PM UTC+2, Max wrote:
>
>
> func mallocList() *List {
> const n = unsafe.Sizeof(List{})
> p := C.malloc(C.ulong(n))
> C.memset(p, C.int(n), 0)
> return (*List)(p)
> }
>

I swapped the arguments to C.memset(). The correct version is:

func mallocList() *List {
const n = C.ulong(unsafe.Sizeof(List{}))
p := C.malloc(n)
C.memset(p, 0, n)
return (*List)(p)
}
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] C.malloc of Go type?

[Max]

After reading https://golang.org/cmd/cgo/#hdr-Passing_pointers and 
https://blog.golang.org/c-go-cgo,
I am trying to understand if there are valid ways to pass between Go and C 
complicated data structures
with (potentially) lots of pointers.

At the moment this is just a speculative question, but it could quickly 
become useful both for my Go interpreter gomacro
and for other similar tasks (I am thinking at least about 
https://github.com/gijit/gi) that need to pass arbitrary
data structures between compiled Go code and the interpreter itself (which 
may not be written in Go).

The question is: is it allowed to take the unsafe.Pointer returned by 
C.malloc() and convert it to a pointer to a Go struct type?

In practice: is the following code valid ?

Thanks,

Max

// 
-

package main

/*
#include 
*/
import "C"

import (
"fmt"
"unsafe"
)

type List struct {
Node int
Next *List
}

func mallocList() *List {
const n = unsafe.Sizeof(List{})
p := C.malloc(C.ulong(n))
C.memset(p, C.int(n), 0)
return (*List)(p)
}

func main() {
// if this code is valid, x can contain C pointers and can be passed 
freely to C code,
// thus exchanging complicated data structured between Go and C

x := mallocList()
x.Next = mallocList()

fmt.Printf("%#v\n", x)
fmt.Printf("%#v\n", x.Next)
}

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] cgo and time.After

[Chris Burkert]

Jakob, I think you’re right. I am going to test this as soon as I am back
home. After all I am a beginner in this area and it seems this one fooled
me. I’ll send an update tomorrow.
thanks - Chris

Jakob Borg  schrieb am Sa. 19. Mai 2018 um 21:15:

> On 19 May 2018, at 16:25, Chris Burkert  wrote:
> >
> > case <-time.After(5 * time.Second):
> > fmt.Printf("Progress: %d left from %d\n", remaining, amount)
>
> It's not super clear from your post if you're aware of this already, but
> this case will only fire after the select has been blocked for five
> seconds. If there is any activity on the other cases one of those will
> proceed, you'll get another loop iteration, and another five second timeout
> before status output.
>
> Typically you'd use a five second ticker instead to get a channel event
> every five seconds and use that to print status output.
>
> //jb

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Validation checks in Go

[matthewjuran]

An example is nil map access or concurrent map access both cause panics in 
the runtime 
(https://github.com/golang/go/blob/release-branch.go1.10/src/runtime/hashmap.go#L357).

A useful thing panic without recover does is print the stack trace.

Matt

On Saturday, May 19, 2018 at 11:57:33 AM UTC-5, David Skinner wrote:
>
> https://play.golang.org/p/d_fQWzXnlAm
>
> If you are going to use panic, then choose a place where you can recover 
> gracefully and report the error.
>
> I do agree, that it is an mistake to return an error code if your 
> assignment was to write a function that only has valid input. The software 
> engineer giving you the assignment may be doing data validation else where 
> and is wrapping a higher level function with a defer to deal with errors. 
> If you are working on a team, it is best to produce what is expected, not 
> something better.
>
> On Fri, May 18, 2018 at 7:33 PM  wrote:
>
>> I may have misunderstood the question. I follow the idea of panic when 
>> the program is in an invalid state.
>>
>> If Divide can receive any input then this is probably a better API:
>>
>> func Divide(a, b float64) (float64, error) {
>>
>> where you would return an ErrDivideByZero made with errors.New as a 
>> global exported var instead of panicking.
>>
>> But if Divide can only receive valid input then that assert seems 
>> appropriate to me.
>>
>> Matt
>>
>> On Monday, May 14, 2018 at 7:38:32 PM UTC-5, Tristan Muntsinger wrote:
>>>
>>> Is it reasonable to use a function like "Assert" below to do validation 
>>> checking in Go?  If not, why not?
>>>
>>> func Assert(t bool, msg string) {
>>> if !t {
>>> debug.SetTraceback("all")
>>> debug.PrintStack()
>>> log.Fatal("Assertion failed: " + msg)
>>> }
>>> }
>>>
>>> func Divide(a float64, b float64) float64 {
>>> Assert(b != 0, "divide by 0")
>>> return a / b
>>> }
>>>
>>> func main() {
>>> fmt.Println(Divide(10, 5))
>>> }
>>>
>>> Thanks,
>>> -Tristan
>>>
>>> -- 
>> 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/viuz4JTVelE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com .
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] cgo and time.After

[Jakob Borg]

On 19 May 2018, at 16:25, Chris Burkert  wrote:
> 
> case <-time.After(5 * time.Second):
> fmt.Printf("Progress: %d left from %d\n", remaining, amount)

It's not super clear from your post if you're aware of this already, but this 
case will only fire after the select has been blocked for five seconds. If 
there is any activity on the other cases one of those will proceed, you'll get 
another loop iteration, and another five second timeout before status output.

Typically you'd use a five second ticker instead to get a channel event every 
five seconds and use that to print status output.

//jb

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Validation checks in Go

[David Skinner]

https://play.golang.org/p/d_fQWzXnlAm

If you are going to use panic, then choose a place where you can recover
gracefully and report the error.

I do agree, that it is an mistake to return an error code if your
assignment was to write a function that only has valid input. The software
engineer giving you the assignment may be doing data validation else where
and is wrapping a higher level function with a defer to deal with errors.
If you are working on a team, it is best to produce what is expected, not
something better.

On Fri, May 18, 2018 at 7:33 PM  wrote:

> I may have misunderstood the question. I follow the idea of panic when the
> program is in an invalid state.
>
> If Divide can receive any input then this is probably a better API:
>
> func Divide(a, b float64) (float64, error) {
>
> where you would return an ErrDivideByZero made with errors.New as a global
> exported var instead of panicking.
>
> But if Divide can only receive valid input then that assert seems
> appropriate to me.
>
> Matt
>
> On Monday, May 14, 2018 at 7:38:32 PM UTC-5, Tristan Muntsinger wrote:
>>
>> Is it reasonable to use a function like "Assert" below to do validation
>> checking in Go?  If not, why not?
>>
>> func Assert(t bool, msg string) {
>> if !t {
>> debug.SetTraceback("all")
>> debug.PrintStack()
>> log.Fatal("Assertion failed: " + msg)
>> }
>> }
>>
>> func Divide(a float64, b float64) float64 {
>> Assert(b != 0, "divide by 0")
>> return a / b
>> }
>>
>> func main() {
>> fmt.Println(Divide(10, 5))
>> }
>>
>> Thanks,
>> -Tristan
>>
>> --
> 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/viuz4JTVelE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ANN] BIFF  (BIFurcation Framework) easy nesting tests

[Gerardo Oscar JT]

Here is BIFF , a small library for 
testing that takes

advantage of scope of nested functions to write

tests faster and more readable. Also prints output

in a BDD style to anyone can understand what is

happening.


When something is broken, it takes you directly

to the buggy line instead of spending time finding

out where is the bad code.


It works fine with acceptance tests and BDD.

https://github.com/fulldump/biff#readme
BIFF is an experiment but I am finding it useful
in several REST API projects.

Please, any kind of feedback is always welcome.

Thanks,
Fulldump



-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] Pion-TURN, a TURN server designed with ease of use and extensibility in mind

[matthewjuran]

Thanks for the kind reply.

Should I change this name, but still keep things like the realm/socket as 
> members still? I think of turn.Server as the global singleton that handles 
> all traffic (UDP or TCP)


An interface is used to allow varying types to have the same logic applied. 
In this case when you assign a Server interface var the only use will be to 
check client authentication. Sometimes people use type assertions on 
interfaces but my opinion is that shouldn’t be a regular thing. The use of 
the interface var vs how it’s done are decoupled.

I am only at 7% coverage, I am working on adding more. It isn't feature 
> complete, I have been more worried about getting users (and getting 
> valuable testing eyes) I will add more tests this weekend.


Unit tests are one part, but I’d be more interested in some sort of overall 
functionality test maybe with load characteristics that perhaps benchmarks. 
If you can show the example works then that may help attract users.

Does that thinking all seem sane?


Well I don’t think a couple extra directories under examples and a few 
extra tens or hundreds of KB will make much difference. Any dependencies 
like Redis would only be needed if building the example. If necessary a 
vendorer could remove files they don’t want.

I use the pkg repo to export things that people might actually want (like 
> generic packet handling) and will be working on another project that uses 
> it (native WebRTC client in Golang)


I saw the STUN things there which seems to match what I was describing.

Matt

On Saturday, May 19, 2018 at 2:07:38 AM UTC-5, se...@pion.ly wrote:
>
> This review is fantastic! I committed what I understood, I have a few 
> questions though.
>
> > Instead of turn.Server a more idiomatic interface name could be 
> something like turn.ClientAuthenticator
> Should I change this name, but still keep things like the realm/socket as 
> members still? I think of turn.Server as the global singleton that handles 
> all traffic (UDP or TCP)
>
> > package server doesn’t have tests and neither does package turn. How did 
> you validate it? Is there validation code you can include?
> I am only at 7% coverage, I am working on adding more. It isn't feature 
> complete, I have been more worried about getting users (and getting 
> valuable testing eyes) I will add more tests this weekend.
>
> > Instead of cmd/simple-turn perhaps you could have 
> examples/simple/main.go. Having a cmd indicates that the cmd is supported, 
> but the authentication is minimal in simple-turn and might not be good for 
> some uses.
>
> The nice thing about simple-turn is for those easy use cases (I want a 
> TURN server that just has 5 users)
> I was thinking of making another repo, maybe turn-examples? That I could 
> make a bunch of examples like Redis integration a REST server etc... I 
> don't want to put that code in this repo because if it is vendored it will 
> cause bloat for people.
> Does that thinking all seem sane?
>
> > Standards like STUN and TURN are an opportunity to make portable code. 
> This layout might lead to clearer and more reusable code:
> Would it be ok if I kept the current layout, but created a `turn-examples` 
> repo? I am mostly worried about bloating code bases that try to vendor 
> pion-turn
>
> I use the pkg repo to export things that people might actually want (like 
> generic packet handling) and will be working on another project that uses 
> it (native WebRTC client in Golang)
>
>
> Thank you so much for the review again! I really appreciate the 
> improvements you have provided.
>
> On Tuesday, May 15, 2018 at 7:46:46 AM UTC-7, matthe...@gmail.com wrote:
>>
>> Hello, thanks for sharing here and thanks for the MIT license. Here’s a 
>> code review.
>>
>> These are my unfiltered opinions. You may not agree with some or any of 
>> them, and some or all of them might not be reasonable to implement. My goal 
>> is to build an ideal way to write Go code by doing code reviews here. My 
>> hope is this feedback is useful to you in this project or in a future 
>> project.
>>
>> In cmd/simple-turn “type myTurnServer struct {}” is a code smell that 
>> hints at overusing interface, but in this case including usersMap in type 
>> myTurnServer would remove the smell. Having the application do 
>> authentication makes sense.
>>
>> (application meaning code using the library)
>>
>> Instead of turn.Server a more idiomatic interface name could be something 
>> like turn.ClientAuthenticator.
>>
>> package server doesn’t have tests and neither does package turn. How did 
>> you validate it? Is there validation code you can include?
>>
>> Perhaps consider embedding Protocol in allocation.FiveTuple.
>>
>> Instead of cmd/simple-turn perhaps you could have 
>> examples/simple/main.go. Having a cmd indicates that the cmd is supported, 
>> but the authentication is minimal in simple-turn and might not be good for 
>> some uses.
>>
>> Standards like STUN and TURN are an 

[go-nuts] cgo and time.After

[Tamás Gulácsi]

Show the code! This should not be cgo error, but user error!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] cgo and time.After

[Chris Burkert]

Dear Gophers,

I am working on a small database tool which checks a database for 
inconsistencies. It does that by calling a stored procedure via sql. 
Unfortunately the database client is available as C-library only but 
luckily there is a go driver for the database/sql package so at least it 
feels like pure go. Of course it is not as it uses cgo under the hood. 
After all I got the basics working based on the following:

   1. a producer goroutine reads from the database, creates the sql 
   statements to be run and passes them into a task channel
   2. eight worker goroutines read from the task channel, run one task at a 
   time on the database and pass the result to a results channel (resChan)
   3. main reads the results from the results channel

So far, so good. Then I wanted to add some progress info. As I know the 
number of checks I added another channel (donChan). Each worker goroutine 
sends an empty struct on that channel after a check has been finished. main 
reads from that channel and decreases the remaining number of checks.

In the end I have something like this:
amount := 42
remaining := amount
for remaining > 0 {
select {
case <-time.After(5 * time.Second):
fmt.Printf("Progress: %d left from %d\n", remaining, amount)
case <-donChan:
remaining--
case res := <-resChan:
fmt.Println(res)
}
}

This is simplified but I hope you get the idea.

The effect is that as long as the eight worker and the producer goroutines 
are running and using the database, I don't see the progress message which 
should be triggered by time.After. To me it looks like the runtime is busy 
with the large cgo threads and cannot handle/schedule the time.After 
goroutine. But when I raise variable amount for testing while the number of 
actual checks is lower (then the for look will run forever) I see the 
Progress output as soon as the worker and the producer goroutines are done. 
So the time.After is not dead - it's just blocked while cgo is used.

And here I would like to ask you for tips and help. If you have an idea and 
you need more details please let me know.

I also came across Dave Cheneys 
post https://dave.cheney.net/2016/01/18/cgo-is-not-go and I believe this is 
what I am suffering from. Unfortunately there is no other database client 
available. It is about SAPs database HANA and I know there is a pure go 
implementation. Unfortunately this one lacks hdbuserstore support which is 
some kind of password store for HANA I need. So I have to use the official 
HANA client based on the C-library.

thanks for any help!
Chris
PS: I am using go 1.10.2 and also tried 1.10 with the same result

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Processing test json data

[vedujoshi]

I see that in go1.10, we can have json formatted "go test" output (by using 
-json flag)
I googled around, but couldn't find a simple way/tool to convert it to 
junitxml format

Any suggestions?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Load balancing with error feedback capabilities

[Ankit Gupta]

@Jakob Can you explain it further? Two different instances of 
ServiceQProperties should each get their own reference of underlying 
sync.Mutex. So, Lock() and Unlock() should be on different objects.

Thanks,
Ankit

On Saturday, May 19, 2018 at 3:39:40 AM UTC+5:30, Jakob Borg wrote:
>
> That also means anyone else can call Lock() and Unlock() on your type. 
> This is often not what you want, unless your type *is* a kind of lock (as 
> opposed to *uses* a lock).
>
> On 18 May 2018, at 23:45, matth...@gmail.com  wrote:
>
> By embedding I meant this:
>
> type ServiceQProperties struct {
> ...
> sync.Mutex
> }
>
> which allows you to call p.Lock() instead of p.REMutex.Lock(). It’s just a 
> personal preference that I was happy about when I learned about it.
>
>
>
-- 
*::DISCLAIMER::




The contents of this e-mail and any attachments are confidential and 
intended for the named recipient(s) only.E-mail transmission is not 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted,lost, destroyed, arrive late or incomplete, or may contain 
viruses in transmission. The e mail and its contents(with or without 
referred errors) shall therefore not attach any liability on the originator 
or redBus.com. Views or opinions, if any, presented in this email are 
solely those of the author and may not necessarily reflect the views or 
opinions of redBus.com. Any form of reproduction, dissemination, copying, 
disclosure, modification,distribution and / or publication of this message 
without the prior written consent of authorized representative of redbus. 
com is strictly prohibited. If you have received this 
email in error please delete it and notify the sender immediately.Before 
opening any email and/or attachments, please check them for viruses and 
other defects.*

-- 
*::DISCLAIMER::




The contents of this e-mail and any attachments are confidential and 
intended for the named recipient(s) only.E-mail transmission is not 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted,lost, destroyed, arrive late or incomplete, or may contain 
viruses in transmission. The e mail and its contents(with or without 
referred errors) shall therefore not attach any liability on the originator 
or redBus.com. Views or opinions, if any, presented in this email are 
solely those of the author and may not necessarily reflect the views or 
opinions of redBus.com. Any form of reproduction, dissemination, copying, 
disclosure, modification,distribution and / or publication of this message 
without the prior written consent of authorized representative of redbus. 
com is strictly prohibited. If you have received this 
email in error please delete it and notify the sender immediately.Before 
opening any email and/or attachments, please check them for viruses and 
other defects.*

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Load balancing with error feedback capabilities

[Ankit Gupta]

Hi Matt,

Ok, if you meant the type embedding -- I usually prefer it for composition 
purpose, so that I can pass around the composed type (or pointer) to 
function calls. Did not find any such need.

I haven’t gotten far enough into network services to have much to say about 
> the features although maybe I will in the future. I was curious about this:
>
> The buffered requests are forwarded in FIFO order when the service is 
>> available next.
>
>
> wouldn’t you want to do these concurrently if possible?
>

I did give it a thought before implementing, but I considered this 
situation - the cluster is down for x mins, and due to the fact no requests 
are getting forwarded, the request buffer fills up quickly and might reach 
the user defined concurrency limit. Now when the cluster is up, and there 
are active requests being accepted too, whom should I give preference to? 
Because I maintain a central work queue for both active and deferred 
requests, I let the program flow decide the order of processing. Perhaps I 
can build an approach to have deferred requests run concurrently if there 
are no active requests in queue and switch back to sequential if there are. 
Or it can be another user defined parameter.

Thanks,
Ankit


On Saturday, May 19, 2018 at 3:16:08 AM UTC+5:30, matthe...@gmail.com wrote:
>
> By embedding I meant this:
>
> type ServiceQProperties struct {
> ...
> sync.Mutex
> }
>
> which allows you to call p.Lock() instead of p.REMutex.Lock(). It’s just a 
> personal preference that I was happy about when I learned about it.
>
> One thought here is you could make it a *sync.Mutex and not use a pointer 
> in these function arguments. Maps vars are pointers so you are doing a 
> double dereference when accessing RequestErrorLog. This avoids (*sqp) but 
> there may be extra memory used and work done to copy the entire struct var 
> as an argument. If you get into performance details I would look at pprof 
> or package testing benchmarking to decide if it matters, but I try to 
> choose cleanest code first.
>
> Thanks for sharing your verification approach.
>
> I haven’t gotten far enough into network services to have much to say 
> about the features although maybe I will in the future. I was curious about 
> this:
>
> The buffered requests are forwarded in FIFO order when the service is 
>> available next.
>
>
> wouldn’t you want to do these concurrently if possible?
>
> Matt
>
> On Friday, May 18, 2018 at 11:50:56 AM UTC-5, Ankit Gupta wrote:
>>
>> Hi Matt,
>>
>> First of all, thanks so much for the review.
>>
>> I will revisit the package structure and take care of err handling in a 
>> more idiomatic way. Few points - 
>>
>> - The mutex is embedded in model.ServiceQProperties. Here is the 
>> definition in model.balancer_properties.go - 
>>
>> type ServiceQProperties struct {
>> ...
>> REMutex sync.Mutex
>> }
>>
>> This is used in two places - error logging to service map in 
>> service_error.go and reading in select_service.go.
>>
>> - I validated 3 things (all tests were done on a cluster of aws t2 medium 
>> linux machines) -  
>>
>> a) Program should reduce probability of selection of errored nodes - this 
>> was done by continously bringing 1 to n-1 services down/up and noting the 
>> trend of requests sent to each node after every state change. As an 
>> example, for a 3 node cluster with 1 node down for 2 mins, the probability 
>> of selection of that node reduced (from 33%) by around 1-2% on each 
>> subsequent hit.
>>
>> b) For performance testing, I used apache bench for issuing large number 
>> of concurrent requests/issuing requests within a time frame and 
>> benchmarking against nginx. There was a 10% difference on average that is 
>> attributed to the fact that I preprocess (parse/store) all requests before 
>> forwarding and that the code is not the most optimzed version right now.
>>
>> c) For deferred queue functionality, I specifically wanted to test 
>> scenarios where both active and deferred requests are to be sent out 
>> simultaneously and if user defined concurrency limits are still valid.
>>
>> Let me know if I should provide more details on a specific feature.
>>
>> Thanks,
>> Ankit
>>
>> On Friday, May 18, 2018 at 8:21:12 PM UTC+5:30, matthe...@gmail.com 
>> wrote:
>>>
>>> Hi Ankit, thanks for the Apache license and for sharing here. Here’s a 
>>> code review.
>>>
>>> These are my unfiltered opinions and I hope that they are useful.
>>>
>>> Without looking at any code yet, the packages might not be idiomatic. 
>>> Packages should contain specific behavior that can be decoupled from the 
>>> application. These concepts could be represented as files and symbols in 
>>> package main.
>>>
>>> SQP_K_LISTENER_PORT might be more regularly represented as 
>>> SQPKListenerPort.
>>>
>>> In config_manager_test.go you could embed model.ServiceQProperties and 
>>> error in type Properties for better readability.
>>>
>>> The newlines in 

[go-nuts] Re: [ANN] Pion-TURN, a TURN server designed with ease of use and extensibility in mind

[sean]

This review is fantastic! I committed what I understood, I have a few 
questions though.

> Instead of turn.Server a more idiomatic interface name could be something 
like turn.ClientAuthenticator
Should I change this name, but still keep things like the realm/socket as 
members still? I think of turn.Server as the global singleton that handles 
all traffic (UDP or TCP)

> package server doesn’t have tests and neither does package turn. How did 
you validate it? Is there validation code you can include?
I am only at 7% coverage, I am working on adding more. It isn't feature 
complete, I have been more worried about getting users (and getting 
valuable testing eyes) I will add more tests this weekend.

> Instead of cmd/simple-turn perhaps you could have 
examples/simple/main.go. Having a cmd indicates that the cmd is supported, 
but the authentication is minimal in simple-turn and might not be good for 
some uses.

The nice thing about simple-turn is for those easy use cases (I want a TURN 
server that just has 5 users)
I was thinking of making another repo, maybe turn-examples? That I could 
make a bunch of examples like Redis integration a REST server etc... I 
don't want to put that code in this repo because if it is vendored it will 
cause bloat for people.
Does that thinking all seem sane?

> Standards like STUN and TURN are an opportunity to make portable code. 
This layout might lead to clearer and more reusable code:
Would it be ok if I kept the current layout, but created a `turn-examples` 
repo? I am mostly worried about bloating code bases that try to vendor 
pion-turn

I use the pkg repo to export things that people might actually want (like 
generic packet handling) and will be working on another project that uses 
it (native WebRTC client in Golang)


Thank you so much for the review again! I really appreciate the 
improvements you have provided.

On Tuesday, May 15, 2018 at 7:46:46 AM UTC-7, matthe...@gmail.com wrote:
>
> Hello, thanks for sharing here and thanks for the MIT license. Here’s a 
> code review.
>
> These are my unfiltered opinions. You may not agree with some or any of 
> them, and some or all of them might not be reasonable to implement. My goal 
> is to build an ideal way to write Go code by doing code reviews here. My 
> hope is this feedback is useful to you in this project or in a future 
> project.
>
> In cmd/simple-turn “type myTurnServer struct {}” is a code smell that 
> hints at overusing interface, but in this case including usersMap in type 
> myTurnServer would remove the smell. Having the application do 
> authentication makes sense.
>
> (application meaning code using the library)
>
> Instead of turn.Server a more idiomatic interface name could be something 
> like turn.ClientAuthenticator.
>
> package server doesn’t have tests and neither does package turn. How did 
> you validate it? Is there validation code you can include?
>
> Perhaps consider embedding Protocol in allocation.FiveTuple.
>
> Instead of cmd/simple-turn perhaps you could have examples/simple/main.go. 
> Having a cmd indicates that the cmd is supported, but the authentication is 
> minimal in simple-turn and might not be good for some uses.
>
> Standards like STUN and TURN are an opportunity to make portable code. 
> This layout might lead to clearer and more reusable code:
>
> github.com/pions/turnhost
> library code files that simplify making a TURN host
> /examples
> /simple
> main.go
> /turn
> library code files implementing the symbols and logic of the 
> standards
>
> Can you explain the github.com/pions/pkg/stun pattern? There is no pkg 
> directory included in the base repo.
>
> Thanks,
> Matt
>
> On Monday, May 14, 2018 at 4:35:09 PM UTC-5, se...@pion.ly wrote:
>>
>> Hi list!
>>
>> I wrote a TURN server and would love to get feedback/share 
>> https://github.com/pions/turn 
>>
>>
>> If you aren't interested in the code, but just want a TURN server there 
>> are already built releases that work on Windows/Darwin/Linux/FreeBSD and 
>> should just take 5 mins to get running!
>> These are the goals I had in mind when designing it, I was frustrated 
>> with other solutions and feel like it creates a higher barrier of entry to 
>> building WebRTC products then needed.
>>
>>
>> # Easy Setup 
>>
>> The example cmd (simple-turn) is a statically built TURN server, configured 
>> by environment variables. 
>>
>> The entire install setup is 5 commands, on any platform! The goal is that 
>> anyone should be able to run a TURN server on any platform.
>>
>> # Integration first
>> pion-turn makes no assumptions about how you authenticate users, how you 
>> log, or even your topology! Instead of running a dedicated TURN server you
>> can inherit from github.com/pions/turn and set whatever logger you want.
>>
>> # Embeddable
>> You can add this to an existing service. This means all your config files 
>> stay homogeneous instead of having the mismatch that makes it 

[go-nuts] Re: Cgo: using syscall.Select

[Sergey Kamardin]

There are methods which are using raw file descriptors (such 
that https://godoc.org/github.com/mailru/easygo/netpoll#NewDesc).

суббота, 19 мая 2018 г., 2:52:27 UTC+3 пользователь Juliusz Chroboczek 
написал:
>
> > You could also take a look 
> > at https://godoc.org/github.com/mailru/easygo/netpoll 
>
> I don't have a net.Conn, just a raw file descriptor. 
>
> -- Juliusz 
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.