Re: [Python-Dev] Cloning threading.py using proccesses

[Audun Ostrem Nordal]

You may already know about a similar project a friend of mine (hi,
Steffen!) did a few years ago called Python Object Sharing (POSH).  This
was however unix specific and relied on fork and SYSV IPC iirc.  I see
he has a SF projectpage here:

http://poshmodule.sourceforge.net/

(doesn't seem to be a lot of activity there, though).

Best regards

__ 
Audun Ostrem Nordal tel: +41.22.76.74427
CERN IT/IS
1211 Geneve 23
Switzerland 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Richard Oudkerk
> Sent: Monday, October 09, 2006 1:59 PM
> To: python-dev@python.org
> Subject: [Python-Dev] Cloning threading.py using proccesses
> 
> I am not sure how sensible the idea is, but I have had a 
> first stab at writing a module processing.py which is a near 
> clone of threading.py but uses processes and sockets for 
> communication.  (It is one way of avoiding the GIL.)
> 
> I have tested it on unix and windows and it seem to work pretty well.
> (Getting round the lack of os.fork on windows is a bit 
> awkward.) There is also another module dummy_processing.py 
> which has the same api but is just a wrapper round threading.py.
> 
> Queues, Locks, RLocks, Conditions, Semaphores and some other 
> shared objects are implemented.
> 
> People are welcome to try out the tests in test_processing.py 
> contained in the zipfile.  More information is included in 
> the README file.
> 
> As a quick example, the code
> 
> .   from processing import Process, Queue, ObjectManager
> .
> .   def f(token):
> .   q = proxy(token)
> .   for i in range(10):
> .   q.put(i*i)
> .   q.put('STOP')
> .
> .   if __name__ == '__main__':
> .   manager = ObjectManager()
> .   token = manager.new(Queue)
> .   queue = proxy(token)
> .
> .   t = Process(target=f, args=[token])
> .   t.start()
> .
> .   result = None
> .   while result != 'STOP':
> .   result = queue.get()
> .   print result
> .
> .   t.join()
> 
> is not very different from the normal threaded equivalent
> 
> .   from threading import Thread
> .   from Queue import Queue
> .
> .   def f(q):
> .   for i in range(10):
> .   q.put(i*i)
> .   q.put('STOP')
> .
> .   if __name__ == '__main__':
> .   queue = Queue()
> .
> .   t = Thread(target=f, args=[queue])
> .   t.start()
> .
> .   result = None
> .   while result != 'STOP':
> .   result = queue.get()
> .   print result
> .
> .   t.join()
> 
> Richard
> 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blocking a non-blocking socket

[Audun Ostrem Nordal]

> An interesting question has come up in the development of the 
> SSL module.
> 
> The function ssl.wrap_socket() takes a flag, 
> do_handshake_on_connect, which tells it whether to do the SSL 
> handshake before returning an SSLSocket object to the caller. 
>  If the socket being wrapped is non-blocking, the code in 
> wrap_socket() must invoke do_handshake() multiple times, and 
> effectively block until the handshake is done.
> 
> Right now, I'm doing it with this loop:
> 
> if do_handshake_on_connect:
> # have to loop to support non-blocking sockets
> while True:
> try:
> self.do_handshake()
> break
> except SSLError, err:
> if err.args[0] == SSL_ERROR_WANT_READ:
> select.select([self], [], [])
> elif err.args[0] == SSL_ERROR_WANT_WRITE:
> select.select([], [self], [])
> else:
> raise

Hello Bill,

Another way of doing it could be to expose a connect() method on the ssl
objects.  It changes the socket.ssl api, but I'd say it is in the same
spirit as the do_handshake_on_connect parameter since no existing code
will break.  The caller then calls connect() until it does not return
SSL_ERROR_WANT_[WRITE|READ].  This only applies when the underlying
socket is non-blocking and the do_handshake_on_connect parameter is
false.

Arguably, this is similar to how normal sockets are treated in asyncore,
only that he caller must be prepared to respond to (multiple?) readable
and writable events for the connection to be established.


Cheers

Audun
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com