On Mon, Mar 8, 2010 at 9:08 AM, Anselm R Garbe wrote:
> On 8 March 2010 00:05, anonymous wrote:
>> On Sun, Mar 07, 2010 at 11:48:38PM +0100, Uriel wrote:
>>> No, there is a fairly clear consensus about the meaning of 'process',
>>> there is no such consensus regarding 'threads', so being explicit
On 8 March 2010 00:05, anonymous wrote:
> On Sun, Mar 07, 2010 at 11:48:38PM +0100, Uriel wrote:
>> 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'),
On 03/08/2010 01:05 AM, anonymous wrote:
> Erlang is not good to write a port scanner.
Do you have any sane justification for this remarque?
On Sun, Mar 07, 2010 at 11:48:38PM +0100, Uriel wrote:
> On Sat, Mar 6, 2010 at 9:46 PM, anonymous 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
On Sat, Mar 6, 2010 at 9:46 PM, anonymous 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 i
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
On Sat, Mar 6, 2010 at 3:19 PM, Dmitry Maluka wrote:
> Threads are good for concurrency. I guess portscan is not the case.
What 'threads'? Pthreads certainly are not good for anything, and
specially not for concurrency.
uriel
On Sat, Mar 6, 2010 at 11:50 AM, anonymous 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 hostp
On Sat, Mar 06, 2010 at 01:50:39PM +0300, anonymous 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
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 j
I will take a look at it as soon as posible :)
thanks
On Thu, Mar 04, 2010 at 03:33:53PM +0300, anonymous wrote:
> On Wed, Mar 03, 2010 at 03:25:38PM -0600, eze.program...@gmail.com wrote:
> > I think this is a good project idea, and it would prove more than useful
> > also im looking forward to th
On Thu, Mar 4, 2010 at 1:49 PM, Anselm R Garbe wrote:
> On 4 March 2010 12:33, anonymous wrote:
>> On Wed, Mar 03, 2010 at 03:25:38PM -0600, eze.program...@gmail.com wrote:
>>> I think this is a good project idea, and it would prove more than useful
>>> also im looking forward to the simple port
On Thu, Mar 04, 2010 at 11:00:05PM +0300, anonymous wrote:
> On Thu, Mar 04, 2010 at 08:14:17PM +0200, Dmitry Maluka wrote:
> > Maybe I miss something, but why not just output results as far as hosts
> > are scanned? Output isn't that slow to use threads.
>
> The main idea was abstraction: scannin
On Thu, Mar 04, 2010 at 08:14:17PM +0200, Dmitry Maluka wrote:
> Maybe I miss something, but why not just output results as far as hosts
> are scanned? Output isn't that slow to use threads.
The main idea was abstraction: scanning function just pass scanned host
to next stage instead of calling ou
On Thu, Mar 04, 2010 at 03:33:53PM +0300, anonymous wrote:
> On Wed, Mar 03, 2010 at 03:25:38PM -0600, eze.program...@gmail.com wrote:
> > I think this is a good project idea, and it would prove more than useful
> > also im looking forward to the simple port scanner, these project ideas
> > have ca
> What about fork()? Nowadays hardware is so powerful ;) fork() results
> in nicer code ;)
Creating thread is not as complex as passing host structures. For example,
libthread from Plan 9 has channels. With pthread I should use condition
variables and mutexes to implement queue.
On 4 March 2010 12:33, anonymous wrote:
> On Wed, Mar 03, 2010 at 03:25:38PM -0600, eze.program...@gmail.com wrote:
>> I think this is a good project idea, and it would prove more than useful
>> also im looking forward to the simple port scanner, these project ideas
>> have caugth my attention.
>
On Wed, Mar 03, 2010 at 03:25:38PM -0600, eze.program...@gmail.com wrote:
> I think this is a good project idea, and it would prove more than useful
> also im looking forward to the simple port scanner, these project ideas
> have caugth my attention.
I have already posted a thread about port scann
18 matches
Mail list logo
