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

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:

---
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.
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.