On Sat, Mar 06, 2010 at 08:08:34PM +0100, Uriel wrote:
> Go has no threads, they are called goroutines for a very important
> reason: to avoid the ambiguous and totally confused meaning of
> 'threads' which makes serious and useful discussion of concurrency
> almost impossible as long as that word is involved.
Agree, I should have called them goroutines. But from the point of
programmer they are still functions, executing concurrently in the same
address space. As http://golang.org/doc/go_lang_faq.html#goroutines says:
"The programmer sees none of this, which is the point." It is more about
implementation, but right, concurrency mechanism is called 'goroutines'
in Go.
> Then stop using fucking pthreads, only masochistic retards use
> pthreads from any apps, use libtask or libthread, or Go, but for the
> love of all that is holy stop using the insanity that is pthreads,
> there is simply no excuse to do so.
Go has no raw sockets and no alternatives to it. In Plan 9 it is possible
to call dial(..., 0, 0, 0) to create file descriptor that accepts raw
packets (IPv4, IPv6 etc., depends on first argument of dial). Go libpcap
bindings are not fully implemented now and there is no network device
like in Plan 9 on some systems.
portscan compiles when I include u.h, libc.h and thread.h and set CC=9c,
LD=9l, I can try to switch to libthread.
> Again, your point might be valid (for some definitions of 'thread'
> perhaps), but please stop using the word 'thread', you are just
> causing confusion, it means completely different things for everyone.
What is better? Call them coroutines and assume that cooperative
multitasking is dead? Or something like 'threads as in libthread',
'threads as in pthreads' etc.? I have always thinked 'thread' is defined
as good as 'process', isn't it?
Received on Sat Mar 06 2010 - 20:46:06 UTC
This archive was generated by hypermail 2.2.0 : Sat Mar 06 2010 - 20:48:03 UTC