Re: [go-nuts] Re: Reading os.Stdin, Unbuffered

[Robert Solomon]

Thanks

On Nov 28, 2017 8:03 PM, "Robert Solomon"  wrote:

I trying to learn how to use pseudo-terminal-go.  It works fine under
Ubuntu 16.04 amd64.  But not fine on win10 64 bit.

go get github.com/carmark/pseudo-terminal-go/terminal

#github.com/carmark/pseudo-terminal-go/terminal
github.com\carmark\pseudo-terminal-go\terminal\terminal.go:715:15:
Undefined State
github.com\carmark\pseudo-terminal-go\terminal\terminal.go:719:2::
Undefined Restore
github.com\carmark\pseudo-terminal-go\terminal\terminal.go:724:18:
Undefined MakeRaw

I tried it with the -u flag also and got the same result.  And it doesn't
matter if I use \ or / on that command line.

I also use github's termbox-go on this win10 box, and that works fine.

What's up?

--rob solomon

On Monday, November 27, 2017 at 9:59:52 AM UTC-5, dc0d wrote:
>
> Is there a way to read from `os.Stdin` in an unbuffered way? (Not waiting
> for a `\n` or anything).
>
-- 
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/NvD-pOTASIk/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] net/http 404 error handling

[Nathan Fisher]

Hi All,

I came across this issue on GitHub relating to 404 handling in which Brad
F. said net/http will not implement templating.

https://github.com/golang/go/issues/10707

Perhaps a silly question but why not change http.NotFound into a function
pointer like this:

```
var NotFound = func(w ResponseWriter, r *Request) {
  Error(w, "404 page not found", StatusNotFound)
}
```
This would allow it to be replaced on app start-up via init(), main(), etc.

It seems a quicker and cleaner solution to the boiler plate required for a
custom response writer and would maintain backwards compatibility.

The main drawback I see to it would be a nil pointer check (in which case
it could default to old behaviour).

Thoughts?

Kind regards,
Nathan
-- 
- sent from my mobile

-- 
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] Building a select friendly condition type

[Ian Lance Taylor]

On Wed, Nov 29, 2017 at 9:32 PM, Dave Cheney  wrote:
>
> Anyone for a round of code golf?
>
> I'm working on a piece of code for a streaming gRPC server and have found
> myself in the position that I need to wait for a notification event (in this
> case that a cache has been updated and I need to stream the results to the
> client) or a context.Done event. There may be multiple gRPC clients, and
> they may come and go without warning. Thus I'm in need of a sync.Cond type
> that works with select.
>
> I've coded this up, which appears to do the job
>
> https://play.golang.org/p/pMZHwA1AD-
>
> But I'm wondering if others have found themselves in the same position, and
> if so, what were your solutions? Am I missing something, will my cond loose
> notifications, or can it be simplified?

See also https://golang.org/issue/16620.

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

[go-nuts] Re: Building a select friendly condition type

[Steven Harris]

On Thursday, November 30, 2017 at 12:32:10 AM UTC-5, Dave Cheney wrote:
>
> But I'm wondering if others have found themselves in the same position, 
> and if so, what were your solutions?
>

I'm not sure if this approach satisfies all of your requirements, but if 
you want those registering to be notified of any changes that occur after 
their call to Register returns, and you don't mind having to "close" the 
condition value, take a look at this Playground sample 
. The implementation is more complex, 
but the caller juggles less state.

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

-- 
Steven E. Harris

-- 
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: Sort a huge slice of data around 2GB

[Slawomir Pryczek]

It should be very simple if you have additional 2G of memory. You divide 
the data to X parts where X is power of 2 and X needs to be less than 
number of cores available. Eg. for 2000MB it can be 250x8. Then you sort it 
in paralell using built-in sorting function and at the end you just 
concatenate the arrays by scanning them and picking smallest element as you 
move forward. You turn 250x8 => 500x4 => 1000x2 => 2000.

It should take about 15-20 minutes to write, and the sorting would probably 
take 5-6 minutes instead of half hour for 8 threads.

In the concat phase you can also paralellize the process more, by getting 
the average of middle elements, then finding position where element is less 
than this value and just breaking the array, at this point into 2 sepatate 
arrays. Eg. if you're doing the last step and you see the element in Arr1 
at position 50 is 91821 and at the same position in Arr2 you have 
1782713 => average is 937267 you're using binary search to find position of 
937267 or anything that is closest in both arrays - then you can break the 
arrays to Arr11 +Arr12 / Arr21 + Arr22 and you just concat Arr11 c Arr21 
and Arr21 c Arr22. But that probably would take more time and is not 
necessairly worth the effor.



W dniu środa, 29 listopada 2017 15:19:13 UTC+1 użytkownik Subramanian K 
napisał:
>
> Hi
>
> I am using native sort provided part of the package and to process 48MB of 
> slice data, it takes ~45sec.
> To run 2GB of data it takes really long time, I am trying to split these 
> to buckets and make it run concurrently, finally need to collate results of 
> all these small sorted buckets.
>
> Do we have any sort package which can sort huge data swiftly?
>
> Regards,
> Subu. K
>

-- 
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: How to check if db connection active after database server restarts ?

[Karan Chaudhary]

If at any point it is to be checked that connection is active or not, 
 `Ping` can be used as stated by Shawn.
And any operation on dirty conn should fail,  as the session is corrupt.

Though,  it seems,  auto-reconnection is already done by database/sql.
https://github.com/golang/go/issues/5718

On Wednesday, 29 November 2017 19:49:13 UTC+5:30, Nupur Bansal wrote:
>
> Hi All,
>
> I have built a Golang application based on REST services that connects to 
> different databases and fetches results.
> When 1 url is hit then if a connection does not already exist, it is 
> created. If it already exists then it is used as such. Connection is being 
> stored in a global variable that is being passed among packages.
>
> *I want to know how I will be able to check if my connection exists or not 
> in case once my db goes down and then is restarted. In that case the 
> session in my global variable will not be empty but will be broken.*
> *How to check if session variable has active connection or not ? *
>

-- 
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: profiling webserver with pprof and router middleware

[Karan Chaudhary]

Attaching png:




On Thursday, 30 November 2017 19:09:04 UTC+5:30, Karan Chaudhary wrote:
>
> Are you just trying to see how heap allocation can be seen using 
> debug/pprof?  
>
> Maybe you're allocating too less.  Try to allocate exponentialy.
>
> package main
>
> import (
> "log"
> "net/http"
> "time"
>
> _ "net/http/pprof"
> )
>
> func expalloc() {
> x := make([]int, 0)
> for i := 0; i < 10; i++ {
> x = append(x, i)
> x = append(x, x...)
> }
>
> time.Sleep(10 * time.Second)
> }
>
> func main() {
> go func() {
> log.Println(http.ListenAndServe("localhost:6060", nil))
> }()
>
> expalloc()
>
> }
>
> Allocations on my machine (reduce 50 to smaller number as the program 
> might go out of memory):
>
>
> 
>
>
>
>
> On Wednesday, 29 November 2017 19:47:11 UTC+5:30, basti skalendudler wrote:
>>
>> Does noone have an idea? :(
>>
>> Am Montag, 27. November 2017 13:37:43 UTC+1 schrieb basti skalendudler:
>>>
>>> The go tool pprof command is interactive, so I thought it is enough type 
>>> 'png' to get the image after the benchmark is run
>>>
>>> I tested to start go tool pprof now as well during and after the 
>>> benchmark -> nothing changes
>>>
>>> Am Montag, 27. November 2017 04:37:48 UTC+1 schrieb Karan Chaudhary:

 From the top of my head,  shouldn't the benchmark be done when traffic 
 is being sent to the server and not before it is sent?

 On Sunday, 26 November 2017 00:11:40 UTC+5:30, basti skalendudler wrote:
>
> Hey guiys, I posted a StackOF question two days ago, but so far nobody 
> was able to help me!
>
> I am trying to profile my web server I wrote, but my pprof does not 
> contain any data about the handler func.  
> I am using the httprouter package 
>  by julienschmidt, and 
> want to simply benchmark one of my handlers and see the pprof profile for 
> that. For the benchmarking, I am using go-wrk 
>   
>
> I set up my web server and pprof like this:
>
>
>  // Configure the server
>  server := {
>  Addr:":4000",
>  Handler: router,
>  }
>
>
>  go func() {
>  log.Println(http.ListenAndServe(":6060", nil))
>  }()
>
>
>  // Start the server
>  err = server.ListenAndServe()
>  if err != nil {
>  panic(err)
>  }
>
>
> The router is initialized like this:
>
>   
>   // Create the httprouter
>  router := httprouter.New()
>  // Register all handlers
>  router.GET("/entities/:type/map", h.UseHandler(
> ApiGetEntitiesMapRequest{}, p))
>
>
> And my handler looks like this:
>
>
>  func (req ApiGetEntitiesMapRequest) Handle(r *http.Request, hrp 
> httprouter.Params, p Params) (interface{}, error) {
>  test := make([]string, 0)
>  for i := 0; i < 1000; i++ {
>  test = append(test, "1")
>  test = append(test, "2")
>  // Ensure pprof has some time to collect its data
>  time.Sleep(10)
>  }
>  return test, nil
> }
>
> This handler is just a test, where I dynamically append a lot of 
> elements to a slice. The reason for that is, I wanted to test whether 
> these 
> dynamic allocations are represented in the heap profile of pprof.
>
> Now, what I did was: 
>  
>  - Start my server  
>  - execute **go tool pprof http://localhost:6060/debug/pprof/heap** 
> in my terminal  
>  - then benchmark my handler by executing **go-wrk -no-c -d 5 
> http://localhost:4000/entities/object/map**  
>
> The request works and my benchmark also reports everything correctly. 
> However, when I type **png** in the pprof terminal, I get this graph:
>
>
> 
>
>
> The graph does not contain any information about my handler and the 
> costly heap allocations I did in my handler. What am I doing wrong?
>


-- 
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: profiling webserver with pprof and router middleware

[Karan Chaudhary]

Are you just trying to see how heap allocation can be seen using 
debug/pprof?  

Maybe you're allocating too less.  Try to allocate exponentialy.

package main

import (
"log"
"net/http"
"time"

_ "net/http/pprof"
)

func expalloc() {
x := make([]int, 0)
for i := 0; i < 10; i++ {
x = append(x, i)
x = append(x, x...)
}

time.Sleep(10 * time.Second)
}

func main() {
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()

expalloc()

}

Allocations on my machine (reduce 50 to smaller number as the program might 
go out of memory):






On Wednesday, 29 November 2017 19:47:11 UTC+5:30, basti skalendudler wrote:
>
> Does noone have an idea? :(
>
> Am Montag, 27. November 2017 13:37:43 UTC+1 schrieb basti skalendudler:
>>
>> The go tool pprof command is interactive, so I thought it is enough type 
>> 'png' to get the image after the benchmark is run
>>
>> I tested to start go tool pprof now as well during and after the 
>> benchmark -> nothing changes
>>
>> Am Montag, 27. November 2017 04:37:48 UTC+1 schrieb Karan Chaudhary:
>>>
>>> From the top of my head,  shouldn't the benchmark be done when traffic 
>>> is being sent to the server and not before it is sent?
>>>
>>> On Sunday, 26 November 2017 00:11:40 UTC+5:30, basti skalendudler wrote:

 Hey guiys, I posted a StackOF question two days ago, but so far nobody 
 was able to help me!

 I am trying to profile my web server I wrote, but my pprof does not 
 contain any data about the handler func.  
 I am using the httprouter package 
  by julienschmidt, and 
 want to simply benchmark one of my handlers and see the pprof profile for 
 that. For the benchmarking, I am using go-wrk 
   

 I set up my web server and pprof like this:


  // Configure the server
  server := {
  Addr:":4000",
  Handler: router,
  }


  go func() {
  log.Println(http.ListenAndServe(":6060", nil))
  }()


  // Start the server
  err = server.ListenAndServe()
  if err != nil {
  panic(err)
  }


 The router is initialized like this:

   
   // Create the httprouter
  router := httprouter.New()
  // Register all handlers
  router.GET("/entities/:type/map", h.UseHandler(
 ApiGetEntitiesMapRequest{}, p))


 And my handler looks like this:


  func (req ApiGetEntitiesMapRequest) Handle(r *http.Request, hrp 
 httprouter.Params, p Params) (interface{}, error) {
  test := make([]string, 0)
  for i := 0; i < 1000; i++ {
  test = append(test, "1")
  test = append(test, "2")
  // Ensure pprof has some time to collect its data
  time.Sleep(10)
  }
  return test, nil
 }

 This handler is just a test, where I dynamically append a lot of 
 elements to a slice. The reason for that is, I wanted to test whether 
 these 
 dynamic allocations are represented in the heap profile of pprof.

 Now, what I did was: 
  
  - Start my server  
  - execute **go tool pprof http://localhost:6060/debug/pprof/heap** in 
 my terminal  
  - then benchmark my handler by executing **go-wrk -no-c -d 5 
 http://localhost:4000/entities/object/map**  

 The request works and my benchmark also reports everything correctly. 
 However, when I type **png** in the pprof terminal, I get this graph:


 


 The graph does not contain any information about my handler and the 
 costly heap allocations I did in my handler. What am I doing wrong?

>>>

-- 
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: Building a select friendly condition type

[Dan Mullineux]

Yes then as it looks correct I am sure I couldn't do any better (fwiw). 

If you are happy that volumes of waiters vs notifications wouldn't behave 
as a `leak` then `c.waiters = c.waiters[:0]` is a fair tradeoff vs GC

On Thursday, 30 November 2017 12:26:21 UTC, Dave Cheney wrote:
>
> That is correct. I should have made this clearer; the intent is to fire a 
> notification when the cache has changed since the last time it was sent to 
> the client, knowing how many times it has changed (for example while it's 
> being transmitted a whole bunch of changes may have been applied) is not 
> important.
>
> On Thursday, 30 November 2017 23:16:57 UTC+11, Dan Mullineux wrote:
>>
>> The for loop in the main goroutine will lose individual notifications 
>> between each Register in that loop but it looks guaranteed that each 
>> Register will know if at least one Notification happened after it last knew 
>> about a Notification. So if that was, and it sounds like it was, the 
>> intention, lgtm.
>>
>>
>>
>>
>>
>> On Thursday, 30 November 2017 05:32:10 UTC, Dave Cheney wrote:
>>>
>>> Hello,
>>>
>>> Anyone for a round of code golf?
>>>
>>> I'm working on a piece of code for a streaming gRPC server and have 
>>> found myself in the position that I need to wait for a notification event 
>>> (in this case that a cache has been updated and I need to stream the 
>>> results to the client) or a context.Done event. There may be multiple gRPC 
>>> clients, and they may come and go without warning. Thus I'm in need of a 
>>> sync.Cond type that works with select. 
>>>
>>> I've coded this up, which appears to do the job
>>>
>>> https://play.golang.org/p/pMZHwA1AD-
>>>
>>> But I'm wondering if others have found themselves in the same position, 
>>> and if so, what were your solutions? Am I missing something, will my cond 
>>> loose notifications, or can it be simplified?
>>>
>>> Thanks
>>>
>>> Dave
>>>
>>

-- 
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: Building a select friendly condition type

[Artyom Pervukhin]

Dave, you’re absolutely right about the possibility of losing channel on lines 
43-47, in my use case that was not an issue because of serialized Notify calls.

On a second look I see a way to simplify my code essentially to this: 
https://play.golang.org/p/F8g-ltlXao  , 
which I believe solves all shortcomings of the previous version.

> On Nov 30, 2017, at 15:34, Dave Cheney  wrote:
> 
> thanks for sharing your implementation. I have a few questions.
> 
> 1. is NewCond needed? Is this sufficient?
> 
> var c Cond
> c.Notify()
> 
> 2. In notify, is the two arg form of the .(*barr) conversion necessary? If 
> the value is not initialised then the assertion to *barr will fail. If it is 
> initiased then the assertion will pass and therefore b is not nil.
> 
> 3. I wonder if channels can be lost on line 43-47. For example like 44 
> succceds and the first goroutine enters the block but has not yet reached 
> line 45, meanwhile a second goroutine enters line 43, fails the condition at 
> line 44 and then overwrites the value stored on line 47, then the first 
> goroutine completes the block and itself reaches line 47 overwriting the 
> value stored in the atomic value. At this point there may be two channels 
> being waited on by callers to Block, but one has been lost permanently. 
> 
> On Thursday, 30 November 2017 22:51:08 UTC+11, Artyom Pervukhin wrote:
> Hi, 
> 
> Some time ago I had a similar use-case and came up with the following 
> pattern: https://play.golang.org/p/zQglq3ObvH 
>  — it's based on guarantee that receive 
> operation on a closed channel always proceeds immediately. 
> 
> 
> -- 
> 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/Uxo-gS0qbqA/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] Re: Building a select friendly condition type

[Dave Cheney]

thanks for sharing your implementation. I have a few questions.

1. is NewCond needed? Is this sufficient?

var c Cond
c.Notify()

2. In notify, is the two arg form of the .(*barr) conversion necessary? If 
the value is not initialised then the assertion to *barr will fail. If it 
is initiased then the assertion will pass and therefore b is not nil.

3. I wonder if channels can be lost on line 43-47. For example like 44 
succceds and the first goroutine enters the block but has not yet reached 
line 45, meanwhile a second goroutine enters line 43, fails the condition 
at line 44 and then overwrites the value stored on line 47, then the first 
goroutine completes the block and itself reaches line 47 overwriting the 
value stored in the atomic value. At this point there may be two channels 
being waited on by callers to Block, but one has been lost permanently. 

On Thursday, 30 November 2017 22:51:08 UTC+11, Artyom Pervukhin wrote:
>
> Hi, 
>
> Some time ago I had a similar use-case and came up with the following 
> pattern: https://play.golang.org/p/zQglq3ObvH — it's based on guarantee 
> that receive operation on a closed channel always proceeds immediately. 
>
>

-- 
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: Building a select friendly condition type

[Dave Cheney]

That is correct. I should have made this clearer; the intent is to fire a 
notification when the cache has changed since the last time it was sent to 
the client, knowing how many times it has changed (for example while it's 
being transmitted a whole bunch of changes may have been applied) is not 
important.

On Thursday, 30 November 2017 23:16:57 UTC+11, Dan Mullineux wrote:
>
> The for loop in the main goroutine will lose individual notifications 
> between each Register in that loop but it looks guaranteed that each 
> Register will know if at least one Notification happened after it last knew 
> about a Notification. So if that was, and it sounds like it was, the 
> intention, lgtm.
>
>
>
>
>
> On Thursday, 30 November 2017 05:32:10 UTC, Dave Cheney wrote:
>>
>> Hello,
>>
>> Anyone for a round of code golf?
>>
>> I'm working on a piece of code for a streaming gRPC server and have found 
>> myself in the position that I need to wait for a notification event (in 
>> this case that a cache has been updated and I need to stream the results to 
>> the client) or a context.Done event. There may be multiple gRPC clients, 
>> and they may come and go without warning. Thus I'm in need of a sync.Cond 
>> type that works with select. 
>>
>> I've coded this up, which appears to do the job
>>
>> https://play.golang.org/p/pMZHwA1AD-
>>
>> But I'm wondering if others have found themselves in the same position, 
>> and if so, what were your solutions? Am I missing something, will my cond 
>> loose notifications, or can it be simplified?
>>
>> Thanks
>>
>> Dave
>>
>

-- 
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: Building a select friendly condition type

[Dan Mullineux]

The for loop in the main goroutine will lose individual notifications 
between each Register in that loop but it looks guaranteed that each 
Register will know if at least one Notification happened after it last knew 
about a Notification. So if that was, and it sounds like it was, the 
intention, lgtm.





On Thursday, 30 November 2017 05:32:10 UTC, Dave Cheney wrote:
>
> Hello,
>
> Anyone for a round of code golf?
>
> I'm working on a piece of code for a streaming gRPC server and have found 
> myself in the position that I need to wait for a notification event (in 
> this case that a cache has been updated and I need to stream the results to 
> the client) or a context.Done event. There may be multiple gRPC clients, 
> and they may come and go without warning. Thus I'm in need of a sync.Cond 
> type that works with select. 
>
> I've coded this up, which appears to do the job
>
> https://play.golang.org/p/pMZHwA1AD-
>
> But I'm wondering if others have found themselves in the same position, 
> and if so, what were your solutions? Am I missing something, will my cond 
> loose notifications, or can it be simplified?
>
> Thanks
>
> Dave
>

-- 
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] Building a select friendly condition type

[Artyom Pervukhin]

Hi,

Some time ago I had a similar use-case and came up with the following pattern: 
https://play.golang.org/p/zQglq3ObvH — it's based on guarantee that receive 
operation on a closed channel always proceeds immediately.

-- 
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: Is there a way omit the the additional allocation when passing []byte to C function?

[Владислав Митов]

Thanks a lot. Yeah, that works but that's not actually my code so I'll have 
to check with the guys that own it if it is feasible to change the C code, 
otherwise I'll do the wrapper. 

On Thursday, November 30, 2017 at 1:35:44 AM UTC+2, xingtao zhao wrote:
>
> /* C code:
>
> struct PKCS15_Ret {
> int error_code;
> int len;
> };
>
> struct PKCS15_Ret PKCS15_wrap(int hash_type, octet message, octet receive) 
> {
> int error_code = PKCS15(hashType, , );
> return struct PKCS15_Ret{ error_code, cOct.len };
> }
>
> */
>
> func PKCS15_PLAIN(hashType, RFS int, msg []byte) ([]byte, error) {
> // input
> mOct := C.octet{
> C.int(len(msg)),
> C.int(len(msg)),
> (*C.char)(unsafe.Pointer([0])),
> }
>
> // output
> r := make([]byte, RFS)
> cOct := C.octet{
> C.int(0),
> C.int(RFS),
> (*C.char)(unsafe.Pointer([0])),
> }
>
> rtn := C.PKCS15_wrap(C.int(hashType), mOct, cOct)
>
> if rtn.error_code != 1 {
> return nil, {code: int(rtn.error_code)}
> }
>
> return r[:rtn.len], nil
> }
>
>
> On Wednesday, November 29, 2017 at 3:12:31 PM UTC-8, xingtao zhao wrote:
>>
>> Make your C function to accept octet parameter, instead of *octet parameter? 
>> Then there will be no allocations.
>>
>> On Wednesday, November 29, 2017 at 2:39:38 PM UTC-8, Владислав Митов 
>> wrote:
>>>
>>> So no way around 4 allocations for 2 values? 
>>
>>

-- 
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.