Concurrency models (was: Timer)

[Alan Kennedy]

[Alan Kennedy]
>> And the patchy support for SSL in asynch frameworks is another
>> fundamental problem.

[Alex Martelli]
> Hmmm, what's wrong with Twisted+pyOpenSSL...?  Seems to work fine...

I haven't used that particular combination.

I was going to followup my own post to mention that my statement was
not in any way meant to be slight to any of the providers of python
SSL. For example, Ng Pheng Siong has put a lot of work into getting
M2Crypto SSL working in non-blocking mode.

My understanding is that using SSL in non-blocking mode is problematic
because SSL-level packets can trigger readiness notification on an SSL
socket when in fact there is no application-level data available.

Here is a link that discusses the problem

http://www.openssl.org/support/faq.html#PROG9

I honestly don't know if all of the asynch models implemented in
python address this problem, and would be happy to be enlightened
and/or proven completely wrong if they have.

Java nio has this problem, which will be addressed in java 1.5

http://www.itworld.com/nl/java_sec/09142001/

[Alan Kennedy]
>> Another point in favour of threads: On a multi-processor box, the
>> thread abstraction generally "automagically" gives you free migration
>> to other processors. You (generally) don't have to change a line of
>> your code: the underlying [OS|VM] takes care of it.

[Alex Martelli]
> *blink*?  Uh, doesn't that depend on how you choose to have your
> threads communicate with each other?  

There is assumption behind my statement: that the underlying [OS|VM]
also maps the memory space of threads running on different processors
so that they coincide, and all objects are shared between threads as
if they were local to the "process" containing the threads.

If I use a Queue.Queue in jython, (AFAICT) the different threads can
be running on different processors, and the Queue.Queue will work just
fine as a synch mechanism.

> The most Pythonic solution
> is generally to have threads communicate via Queue instances.  Can
> you point me to a "cross-process Queue" class for Linux and Windows?

I'd love to. However, python's Queue.Queue class doesn't work across
processes, only across threads. But those threads could still
potentially be running on multiple processors in the same box (see
above re jython).

It'd be nice if we could have a Queue.Queue style IPC mechanism that
worked between processes, and that could be included in the set of
"selectables" for an event-driven framework. Without copious
serialization/pickling. I have stated that several times in this
forum.

> Not a rhetoric question -- I'd LIKE to be able to scale things up that
> way, but see some problems with translating typical Queue use idioms,
> particularly in a cross-platform way, to cross-process:
> -- N1 client-threads posting workrequests to Q and N2 worker-threads
>    peeling workrequests off Q and working on them;
> -- a workrequest including a reference to the Queue instance on
>    which the worker-thread is going to post the response/result

I was interested to read about TupleSpaces from a recent post. Though
I haven't looked into TupleSpaces in detail, I can imagine that
there's lots of de/serialization going on.

Lastly, another area which seems to have patchy support across
operating systems is that of non-blocking file-locks, which would be
required for many event-driven apps.

regards,

-- 
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan:              http://xhaus.com/mailto/alan