On Sun, Mar 07, 2010 at 11:48:38PM +0100, Uriel wrote:
> On Sat, Mar 6, 2010 at 9:46 PM, anonymous <aim0shei_AT_lavabit.com> wrote:
> > 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.
>
> Or use libtask, hell, or even Erlang, there are plenty of options
> better than pthreads. (And yes, I'm well aware that some of them use
> pthreads internally for portability, and I don't care because the
> model they implement is sane and not inherently dependent on
> pthreads.)
libthread from plan9port has no chanclose, is it ok? Same with
libtask. Looks like they are not fully ported. Erlang is not good to
write a port scanner.
> >> 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?
>
> No, there is a fairly clear consensus about the meaning of 'process',
> there is no such consensus regarding 'threads', so being explicit
> saying 'pthreads', or 'CSP threads' (as in 'libthread'), or
> 'goroutines' is the best.
Difference between pthreads and libthread is the way threads communicate
(locks/mutexes vs channels) but 'thread' means the same. Both in pthreads
and in libthread threads are like processes that share the same address
space (everything except registers and stack).
> It is a pity that so many systems (including Plan 9) have decided to
> overload the meaning of the word 'thread' to the point that it has
> become hopelessly useless unless the context is very clear,
> 'goroutines' seemed to me like an awkward term at first, but they are
> a great solution to this terminological mess.
Word 'thread' is used to describe goroutines in
http://golang.org/doc/go_lang_faq.html#goroutines
"When a coroutine blocks, such as by calling a blocking system call,
the run-time automatically moves other coroutines on the same operating
system thread to a different, runnable thread so they won't be blocked."
So every second there is more goroutines than threads, that's why they
have different name. Threads are still here, they are not replaced
by goroutines.
Received on Mon Mar 08 2010 - 00:05:04 UTC
This archive was generated by hypermail 2.2.0 : Mon Mar 08 2010 - 00:12:02 UTC