On Sat, May 4, 2019 at 10:20 PM ThisEndUp wrote:
>
> I am thoroughly frustrated. I have a file named main.html that references a
> css and a js file.
>
> Here's the relevant portion.
>
>
>
>
>
>
> This is in a subdirectory of my GOPATH/src, named learn/webpages, and the css
>
SQL backend introduced race detector blind spot. Writes and reads aren't
transparent to its ThreadSanitizer internals. Misunderstanding isolation
levels and what your application does is the source of nasty race
conditions.
I'm thinking a bit, if there's pure go implementation of ACID
Thanks for the quick response. Unfortunately, when I run that, what I get
is what appears to be a directory listing of webpages
css/
js/
main.css
main.html
It's actually a list of hrefs to these:
css/
js/
main.css
main.html
However, if I
- duplicate the file main.html,
- name the copy
try the non-shell version of Entrypoint:
ENTRYPOINT ["/myapp"]
On Saturday, 4 May 2019 17:29:16 UTC+1, sunto...@gmail.com wrote:
>
> Hi,
>
> I'm trying to create Go web server into small Docker images. Here is
> my Dockerfile:
>
>
> # golang:latest as build-env
> FROM golang:latest AS
ok, I'm banning myself from this forum for a while. Sorry about this. I'm
not right at the moment.
On Sunday, 5 May 2019 21:55:57 UTC+2, Louki Sumirniy wrote:
>
> I think the key thing is the Add function I have written is not concurrent
> safe. I didn't intend it to be as I only had the use
On Sun, May 5, 2019 at 9:56 PM Louki Sumirniy
wrote:
>
> I think the key thing is the Add function I have written is not concurrent
> safe. I didn't intend it to be as I only had the use case of a single thread
> managing a worker pool, and I am pretty sure it is fine for this and for
> larger
I think the key thing is the Add function I have written is not concurrent
safe. I didn't intend it to be as I only had the use case of a single
thread managing a worker pool, and I am pretty sure it is fine for this and
for larger pools it has lower overhead of memory *and* processing.
I have
I didn't intend Add to be used concurrently, by the way. One pool one
thread for the controller.
On Sunday, 5 May 2019 21:09:40 UTC+2, Louki Sumirniy wrote:
>
> If at 13 in the else clause, if I first test for a non-nil wg.ops and
> close it if it's open, I think that stops that channel leak.
If at 13 in the else clause, if I first test for a non-nil wg.ops and close
it if it's open, I think that stops that channel leak.
On Sunday, 5 May 2019 18:32:14 UTC+2, Marcin Romaszewicz wrote:
>
> I've done quite a bit of MP programming over 20+ years now, and skimming
> your code, I see a
Hi, Is there a way to renew a context that has already reached a deadline?
package main
import (
"context"
"fmt"
"time"
)
func sleepAndPrint(ctx context.Context, msg <-chan string, b <-chan bool) {
for {
select {
case <-ctx.Done():
I've done quite a bit of MP programming over 20+ years now, and skimming
your code, I see a number of issues. There are probably a lot more that I
don't. In the latest go playground link
Line14: if "if wg.started {" has a race condition, both on accessing the
variable, and logically, in that two
Define a type:
type Countries []Country
Then, for that type, implement the sql.Scanner and sql.Valuer interfaces.
You could, for example, marshal your state array as a list of comma
separated states. You're not casting, but providing customer
scanners/readers for your data type which convert it
just had to drop an update, I further improved it, now when it stops it
resets itself and you can use Add again, I removed the unnecessary
positive/negative checks and condensed the Add and Done function into an
Add that can take a negative (tried to think of a better word but Modify
and
I figured out that the API of my design had a flaw separating starting the
goroutine and adding a new item, so as you can see in this code, I have
merged them and notice that there is basically no extraneous 'helper'
functions also:
https://play.golang.org/p/hR1sTOAwkOm
The flaw I made
type Country struct {
ID int`json:"id"`
States string `json:"states"`
}
var Countries []Country
func getAllCountries() {
rows, err := db.Query("select id, states from countries")
if err != nil {
astilog.Error(err)
}
defer rows.Close()
for
Ah, my bad! What I meant was that binary.Read will pad when writing to the
struct, unlike memcpy.
On Sat, May 4, 2019 at 10:50 AM Matt Harden wrote:
> Why do you think binary.Read should handle padding for you? Based on the
> documentation, it would be a bug if it did.
>
> On Tue, Apr 30, 2019
On Sunday, May 5, 2019 at 1:09:47 AM UTC+8, Jan Mercl wrote:
>
> On Sat, May 4, 2019 at 6:53 PM T L >
> wrote:
>
> > BTW, the type bar is defined as
> >
> > typedef struct bar bar;
>
> If struct bar is not yet defined at that point then it's an incomplete
> type. So is bar. Not sure if
On Sun, May 5, 2019 at 12:54 PM Louki Sumirniy
wrote:
>
> hang on, sorry to be so chatty on this but I'm learning a lot about handling
> edge cases from this, so I need to comment further
>
> ok, I got it working for that test also:
>
> https://play.golang.org/p/nd_EuCSOWto
>
> I can tell by the
On Sun, May 5, 2019 at 12:45 PM Louki Sumirniy
wrote:
>
> https://play.golang.org/p/5KwJQcTsUPg
>
> I fixed it.
Not really. You've introduced a data race.
jnml@4670:~/src/tmp> cat main.go
package main
type WaitGroup struct {
workers int
ops chan int
}
func New() *WaitGroup
Ahaha! you made a race, actually! I mean I made a race, but that code
exposed it.
I'm gonna just go away for a while. My brain doesn't really seem to be keen
on doing this kind of thinking right at this minute.
On Sunday, 5 May 2019 12:54:25 UTC+2, Louki Sumirniy wrote:
>
> hang on, sorry to
hang on, sorry to be so chatty on this but I'm learning a lot about
handling edge cases from this, so I need to comment further
ok, I got it working for that test also:
https://play.golang.org/p/nd_EuCSOWto
I can tell by the fact you used the 'sync' keyword that you didn't in fact
test what
On Sun, May 5, 2019 at 12:45 PM Louki Sumirniy
wrote:
> The code you have written there has weird non-standard utf-8 code points in
> it.
It was plain ASCII only. You can verify that here:
https://groups.google.com/forum/#!original/golang-nuts/r3N6bM8YnIg/aEYX1qViBAAJ
--
You received this
ok, you found another flaw :) Not adding is now accounted for but waiting
twice isn't.
On Sunday, 5 May 2019 12:27:10 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 12:06 PM Louki Sumirniy
> > wrote:
>
> > Is there ANY other use case for waitgroup other than preventing a
> goroutine leak
https://play.golang.org/p/5KwJQcTsUPg
I fixed it.
The code you have written there has weird non-standard utf-8 code points in
it. It won't make any difference whether you defer the Wait() if no Add is
called the goroutine does not start now.
On Sunday, 5 May 2019 12:27:10 UTC+2, Jan Mercl
and mine is also incorrect. now it handles your test but not intended
operation. :)
On Sunday, 5 May 2019 12:25:29 UTC+2, Louki Sumirniy wrote:
>
> With your (imho incorrect) code, the following small modification defers
> starting the channel until an add has been called and passes the test:
>
On Sun, May 5, 2019 at 12:06 PM Louki Sumirniy
wrote:
> Is there ANY other use case for waitgroup other than preventing a goroutine
> leak or ensuring that it empties the channels at the end of execution?
I don't think this question is related to the correctness of your
shorter implementation
With your (imho incorrect) code, the following small modification defers
starting the channel until an add has been called and passes the test:
https://play.golang.org/p/sEFcwcPMdHF
On Sunday, 5 May 2019 11:54:40 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 11:46 AM Louki Sumirniy
> >
Is there ANY other use case for waitgroup other than preventing a goroutine
leak or ensuring that it empties the channels at the end of execution?
On Sunday, 5 May 2019 11:54:40 UTC+2, Jan Mercl wrote:
>
> On Sun, May 5, 2019 at 11:46 AM Louki Sumirniy
> > wrote:
>
> > That would mean your
On Sun, May 5, 2019 at 11:46 AM Louki Sumirniy
wrote:
> That would mean your code, which breaks this code, also breaks the rule about
> never starting a goroutine without having a way to stop it. My code only
> fails when the caller is also failing.
My code does not even contain a go
I didn't even think of the condition your code exposes. Partly because at
the same time, if I wrote code that starts goroutines and doesn't have a
section to close them, this deadlock condition created would also be
exposing the fact that the worker pool is not being stopped correctly
either.
30 matches
Mail list logo
