On Sat, Mar 6, 2010 at 9:46 PM, anonymous <aim0shei_AT_lavabit.com> wrote:
> 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.
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.)
But there is just no excuse to use pthreads directly.
>> 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.
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.
uriel
Received on Sun Mar 07 2010 - 22:48:38 UTC
This archive was generated by hypermail 2.2.0 : Sun Mar 07 2010 - 23:00:03 UTC