Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #68219 > unrolled thread

Re: which async framework?

Started byAntoine Pitrou <solipsis@pitrou.net>
First post2014-03-11 16:01 +0000
Last post2014-03-12 07:16 -0400
Articles 4 — 4 participants

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: which async framework? Antoine Pitrou <solipsis@pitrou.net> - 2014-03-11 16:01 +0000
    Re: which async framework? Grant Edwards <invalid@invalid.invalid> - 2014-03-11 16:52 +0000
      Re: which async framework? jkn <jkn_gg@nicorp.f9.co.uk> - 2014-03-11 10:13 -0700
      Re: which async framework? Neal Becker <ndbecker2@gmail.com> - 2014-03-12 07:16 -0400

#68219 — Re: which async framework?

FromAntoine Pitrou <solipsis@pitrou.net>
Date2014-03-11 16:01 +0000
SubjectRe: which async framework?
Message-ID<mailman.8049.1394553908.18130.python-list@python.org>
Sturla Molden <sturla.molden <at> gmail.com> writes:
> 
> Chris Withers <chris <at> simplistix.co.uk> wrote:
> > Hi All,
> > 
> > I see python now has a plethora of async frameworks and I need to try 
> > and pick one to use from:
> > 
> > - asyncio/tulip
> > - tornado
> > - twisted
> 
> I'd go for using iocp, epoll and kqueue/kevent directly. Why bother to
> learn a framework? You will find epoll and kqueue/kevent in the select
> module and iocp in pywin32.

Yes, why use a library when you can rewrite it all yourself?
Actually, you should probably issue system calls to the kernel directly,
the libc is overrated (as is portability, I suppose).

Regards

Antoine.

[toc] | [next] | [standalone]


#68227

FromGrant Edwards <invalid@invalid.invalid>
Date2014-03-11 16:52 +0000
Message-ID<lfnf02$q0c$1@reader1.panix.com>
In reply to#68219
On 2014-03-11, Antoine Pitrou <solipsis@pitrou.net> wrote:
> Sturla Molden <sturla.molden <at> gmail.com> writes:
>> 
>> Chris Withers <chris <at> simplistix.co.uk> wrote:
>> > Hi All,
>> > 
>> > I see python now has a plethora of async frameworks and I need to try 
>> > and pick one to use from:
>> > 
>> > - asyncio/tulip
>> > - tornado
>> > - twisted
>> 
>> I'd go for using iocp, epoll and kqueue/kevent directly. Why bother to
>> learn a framework? You will find epoll and kqueue/kevent in the select
>> module and iocp in pywin32.
>
> Yes, why use a library when you can rewrite it all yourself?
> Actually, you should probably issue system calls to the kernel directly,
> the libc is overrated (as is portability, I suppose).

And don't bother with device drivers for the network adapters either.
Just map their PCI regions in to user-space and twiddle the reigisters
directly!  ;)

[I do that when testing PCI boards with C code, and one of these days
I'm going to figure out how to do it with Python.]

-- 
Grant Edwards               grant.b.edwards        Yow! It's a hole all the
                                  at               way to downtown Burbank!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]


#68230

Fromjkn <jkn_gg@nicorp.f9.co.uk>
Date2014-03-11 10:13 -0700
Message-ID<7bee65ea-2779-4d60-b997-889493bec87e@googlegroups.com>
In reply to#68227
Hi Grant

On Tuesday, 11 March 2014 16:52:18 UTC, Grant Edwards  wrote:

[...]
> 
> And don't bother with device drivers for the network adapters either.
> Just map their PCI regions in to user-space and twiddle the reigisters
> directly!  ;)
> 
> [I do that when testing PCI boards with C code, and one of these days
> I'm going to figure out how to do it with Python.]

Heh - just about the first 'real' thing I did in Python, back around 2001
or so, was to write a 'Device Driver' library to allow direct access to
memory-mapped I/O via Python. It compiled under both Windows and Linux
and I proved it using an ISA I/O board with loads of 8255s and LEDs
hanging off it.

As well as a learning exercise it was sort-of intended as a first step
toward robotic control using Python. I hopen to rework it for similar
PCI-based I/O boards (to do the sort of thing you mention), but never got
a round tuit...

    Cheers
    jon N

[toc] | [prev] | [next] | [standalone]


#68272

FromNeal Becker <ndbecker2@gmail.com>
Date2014-03-12 07:16 -0400
Message-ID<mailman.8083.1394622996.18130.python-list@python.org>
In reply to#68227
Grant Edwards wrote:

> On 2014-03-11, Antoine Pitrou <solipsis@pitrou.net> wrote:
>> Sturla Molden <sturla.molden <at> gmail.com> writes:
>>> 
>>> Chris Withers <chris <at> simplistix.co.uk> wrote:
>>> > Hi All,
>>> > 
>>> > I see python now has a plethora of async frameworks and I need to try
>>> > and pick one to use from:
>>> > 
>>> > - asyncio/tulip
>>> > - tornado
>>> > - twisted
>>> 
>>> I'd go for using iocp, epoll and kqueue/kevent directly. Why bother to
>>> learn a framework? You will find epoll and kqueue/kevent in the select
>>> module and iocp in pywin32.
>>
>> Yes, why use a library when you can rewrite it all yourself?
>> Actually, you should probably issue system calls to the kernel directly,
>> the libc is overrated (as is portability, I suppose).
> 
> And don't bother with device drivers for the network adapters either.
> Just map their PCI regions in to user-space and twiddle the reigisters
> directly!  ;)
> 
> [I do that when testing PCI boards with C code, and one of these days
> I'm going to figure out how to do it with Python.]
> 

Use numpy with mmap

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web