Re: [go-nuts] Linux File descriptor question in golang
> On 21 Jul 2016, at 11:02, Homer Li <01jay...@gmail.com> wrote: > > Could I get file path from the file descriptor number ? > OS : Linux > How to write in golang ? On Linux (and indeed most if not all POSIX like systems) one cannot get a file path from the file descriptor number. This is irrespective of programming language used. Consider what happens if you open a file, then unlink it. Or open it then rename it. Or open a file with multiple links to it. Etc. -- Alex Bligh -- 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] calling file.Write() concurrently
> On 5 Jul 2016, at 10:38, Pierre Durand <pierredur...@gmail.com> wrote: > > Hello! > > My code: https://play.golang.org/p/pg-p17UuEW > I'm trying to append lines to a file concurrently. > > My first write() function is buggy, because WriteString() are called by > several goroutines in unexpected order. > > So, I've written writeMutex(), that uses a mutex. > It works as expected, but in my real code, I'd prefer to avoid mutex. > (in my real code write() can write to different files; the file's name is > given as argument) Use one mutex per file then, and make your write() lock the correct mutex. Note that if you have a map of mutexes, you may also need to protect that map with a mutex, but that only needs protecting whilst you access the map with the possibility of a concurrent write; however, be aware of the danger of lock inversion. -- Alex Bligh -- 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] Prevent RTS from creating an OS thread
On 2 Jul 2016, at 05:23, Matt Harden <matt.har...@gmail.com> wrote: > Forking is not safe in Go either. Why? Let's assume one knows what one is doing and doesn't try to use channels etc. -- Alex Bligh -- 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] Prevent RTS from creating an OS thread
> On 30 Jun 2016, at 14:10, Martynas Pumputis <martyn...@gmail.com> wrote:
>
> I see :-/
>
> One very fragile workaround I've had in mind is to replace any
> occurrence of syscall.Syscall by syscall.Rawsyscall within call graph
> of doSomeStuff(). However, the Go scheduler is not truly cooperative,
> so unexpected preemption can happen during the execution (e.g. due to
> a stack growth) which might result in creation of a new OS thread (M).
I've done this in C by creating a new thread and using the method
you describe. Would an alternative approach be to fork() in go
(look at github.com/sevlyar/go-daemon for instance), having previously
set up some IPC, and have your forked process (also in go, and in
the same source code) perform the things that need to be done in
the separate namespace? If you are always using the same alternate
namespace, you then only have IPC overhead, and if you are using
different namespaces each time, it costs a fork() but not an exec().
Alex
> On Thu, Jun 30, 2016 at 3:41 AM, Ian Lance Taylor <i...@golang.org> wrote:
>> On Tue, Jun 28, 2016 at 2:50 PM, Martynas Pumputis <martyn...@gmail.com>
>> wrote:
>>>
>>> Recently I've bumped into a problem when using the Linux network
>>> namespaces in Go.
>>>
>>> In my program I have the following function:
>>>
>>> func do() {
>>>runtime.LockOSThread()
>>>defer runtime.UnlockOSThread()
>>>netns.Set(containerNs)
>>>defer netns.Set(hostNs)
>>>doSomeStuff()
>>> }
>>>
>>> where netns.Set [1] changes the network namespace (does the setns(2)
>>> syscall via syscall.Syscall). The problem with this function is that
>>> during the execution of doSomeStuff() or defer netns.Set(hostNs) the
>>> Go runtime might create a new OS thread (e.g. due to blocking) which
>>> will reside in the same namespace as parent (CLONE_NEWNET is not set
>>> when doing clone(2)). The newly created thread might be used for
>>> scheduling other go-routines which will end up running in the "wrong"
>>> namespace. As a consequence, the go-routines might not be able to
>>> access some netdevs available within the host network namespace or
>>> previously created sockets.
>>>
>>> One workaround to this problem is to shell out a process (e.g. via
>>> exec.Command) which would set the namespace and do doSomeStuff().
>>> However, this approach is sort of ugly, because a) we create
>>> unnecessary process; b) doSomeStuff() cannot be implemented in Go
>>> without special hacks [2].
>>>
>>> Considering a vast adoption of Go within containers software, it's a
>>> bit odd that the runtime does not provide any means to address the
>>> problem. Maybe I'm missing something?
>>
>> You aren't missing anything. Doing this correctly requires runtime
>> support, and that support does not exist. It's not even obvious how
>> to write it, at least not 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Alex Bligh
--
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] A proposal for generic in go
On 21 Jun 2016, at 19:55, 'Axel Wagner' via golang-nuts
<golang-nuts@googlegroups.com> wrote:
> The issue is, that a "KeyValuePair<K, V>" (no matter if you implemented it
> via generics or like you mention via interfaces) is a fundamentally useless
> type and generics encourage people to add useless types. A "KeyValuePair<K,
> V>" is a "struct { Key K, Value V }", plain and simple. It's not an interface
> and it's not a generic type, it's simply a struct.
>
> I agree, that generics are useful, but they seem to be mainly useful for
> people who write "frameworks", not so much for people who write
> "applications" and so far, go is pretty much a language for the latter.
> Whenever people try to justify generics, they do it from a "I want to write a
> framework" POV - and whenever I miss generics, I do because I'm currently
> writing a framework of some kind.
Not sure that's fair.
For background, I'd quite like generics and liked Ian's last proposal quite a
bit, but I also appreciate the cleanliness of go.
An recent example, in an real life application, where generics would have been
useful is as follows.
I had a cache type thing built around a red-black tree, or more precisely two
red black trees. The items were structs, and I needed one RB tree to be ordered
by time of insertion (then key, for uniqueness), and one by key. One red-black
tree dealt with expiries, and one with finding the item. In the absence of
generics, I needed to embed the struct in a 'ByTime' and 'ByItem' struct, each
of which implement a different 'LessThan' method. And everything that accessed
the trees had a bunch of ugly casting from an interface{} to the relevant type.
This does not make for readable code in any form. A RB tree that was
implemented as a generic (and perhaps took a 'LessThan' function as a lambda)
would have been far far cleaner in *my* code.
So saying it's all about being useful for people who write "frameworks" is
unfair. It would actually have made the application code (i.e. the library
user) far easier to read.
Of course it's possible to generate foolish uses (I would however note in
passing that even with KeyValuePair things might not be as simple as you think,
as it would (presumably) require comparability of K type items); however, it's
also possible to perform stupidity with existing go syntax. The question is
whether generics encourage it.
--
Alex Bligh
--
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.
