Re: [dev] Re: Simple port scanner again (was: GSoC 2010)

On Sat, Mar 6, 2010 at 11:50 AM, anonymous <aim0shei_AT_lavabit.com> wrote:
> On Thu, Mar 04, 2010 at 11:17:08PM +0200, Dmitry Maluka wrote:
>> What is the profit from this abstraction? You call remove_scanned()
>> which moves host from host queue to scanned queue; output() takes hosts
>> from scanned queue and calls hostprint() for them; and you do
>> synchronization. Why not just call hostprint() at the beginning?
>
> There are two threads for two tasks. First thread calculates columns
> lengths and outputs results of port scanning. Second thread probe ports
> and send results to first thread.
>
> Moving every task in one thread is like moving every task in one program.
>
> In Go, for example, it is very easy to separate program in multiply threads:

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.

> ---
> package main
>
> import fmt "fmt"
>
> func scan(ch chan int) {
>        for i := 0; i < 10; i++ {
>                ch <- i
>        }
>        close(ch)
> }
>
> func main() {
>        scanned := make(chan int)
>        go scan(scanned)
>        for value := range scanned {
>                fmt.Printf("%d\n", value)
>        }
> }
> ---
>
> I don't think I should move everything in one thread just because pthreads
> sucks. I have implemented something like a channel with pthreads. Code
> is complex not because idea of separating program into threads is bad,
> but because pthreads library is too low-level.

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.

> One way is to rewrite everything in Go, but it is not easy to rewrite
> low-level code because there is no raw sockets and bindings for libpcap
> are not fully implemented. Easier way is to use libthread from plan9port.
>
> Rejecting threads is not good idea at all. Threads idea is a projection
> of unix way. Threads are like programs and channels are like pipes. You
> can write everything without them but you better switch to unix instead.

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.

uriel
Received on Sat Mar 06 2010 - 19:08:34 UTC