Hi folks,
During the development of a Python library which uses under the hood a
C++ library - using Cyhton - we found a deadlock issue between a lock
maintained by the C++ library and the GIL lock.
The problem started to appear at the moment that we tried to offload
all IO operations into an iso
ded mode md5challenge reached about 200.000 more keys !!! I
repeat this test many times and always wins embedded mode !!! What's
happen ?
Also I tested to erase read dependencies from /dev/random, and calculate all
keys from same buffer. In this case embedded mode win always also, and the
d
licit - the const_b is 20 bytes.
My problem it's that don't understand because the same program run into
embedded mode or in bash mode have a different results !!! what do you think
about this ? may be a GIL ?
PD: no seguro que no llego :), a ver si alguien mas se apunta a la discusion
!
led launch some threads this
interpreter will be prepare for handle more one thread with python thread
safe environment, can everybody help me ?
Thks
On Tue, Jun 3, 2008 at 9:58 PM, Pau Freixes <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> First Hello to all, this is my and hope not end m
icle for my blog and I need to make sure about the
current problem with GIL and multi core environments, this picture try to
explain with images the problem for scheduling multiple threads running
python code of same interpreter into multiple cpu cores. Can anyone confirm
to me this picture ?
on, 09 Jun 2008 15:26:09 -0300, Pau Freixes <[EMAIL PROTECTED]>
> escribió:
>
> Surly this is a recurring theme into python dev world, but I need your
>> help
>> for confirm if the follow image it's really
>>
>> http://www.milnou.net/~pfreixes
management : object references, allocation, garbage collector
my question it's exists some paper or book with this themes ?
* Credits : it's a quantitative value related with hours in Spanish
universities.
Thks
--
Pau Freixes
Linux GNU/User
--
http://mail.python.org/mailman/listinfo/python-list
ime.
>dir = start_time.replace(" ", "_").replace(":", "_")
>os.mkdir(dir)
>os.chdir(dir)
>
>queue = Queue.Queue(0)
>
>for i in xrange(32):
>t = threading.Thread(target=worker, name="worker %d" % (i +
> 1))
>t.setDaemon(True)
>t.start()
>
>for id in xrange(start_id, end_id + 1):
>queue.put(id)
>
># When the queue has size zero, exit in three seconds.
>while True:
>if queue.qsize() == 0:
>time.sleep(3)
>break
>
>print now()
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Pau Freixes
Linux GNU/User
--
http://mail.python.org/mailman/listinfo/python-list
- and may be that this week up suspicion to the admin.
May be, you can use httplib [1] for do a persistent connection and reuse
same connection for same thread.
[1] http://www.python.org/doc/2.4.2/lib/httplib-examples.html
--
Pau Freixes
Linux GNU/User
--
http://mail.python.org/mailman/listinfo/python-list
EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/pfreixes%40gmail.com
>
--
Pau Freixes
Linux GNU/User
--
http://mail.python.org/mailman/listinfo/python-list
implement
> search suggestions, similar to Google's "Did you mean... ?" feature.
> Can anyone point me to web pages, journal articles, implementations
> (preferably in Python!), or any other resources in this area?
>
> Thanks!
> --
> http://mail.python.org/mailman/li
ify a different
performance. Or WSGI interface it's more efficient than mod_python interface
?
What do you think about this ?
--
Pau Freixes
Linux GNU/User
--
http://mail.python.org/mailman/listinfo/python-list
t;get more performance?
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Pau Freixes
Linux GNU/User
--
http://mail.python.org/mailman/listinfo/python-list
, Matthieu Brucher <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> The C-API uses references counts as well, so it is not threadsafe.
>
> Matthieu
>
> 2008/6/26 Pau Freixes <[EMAIL PROTECTED]>:
> > But Python C-API[1] it's the main base for extent python with C/c++,
>
> 33 mainobj = PyImport_ExecCodeModule("multiply", (PyObject
> *) python_code);
> (gdb) n
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804e7f6 in PyImport_ExecCodeModuleEx ()
>
> The .pyc file woks just fine in Python interpreter:
&g
assume that it's not solving a real problem and will let it
> quietly die on the vine...
>
> Thank you for your attention!
>
> -bruce
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Pau Freixes
Linux GNU/User
--
http://mail.python.org/mailman/listinfo/python-list
ject ?
Bye and thks to all
--
Pau Freixes
Linux GNU/User
--
http://mail.python.org/mailman/listinfo/python-list
17 matches
Mail list logo