[zeromq-dev] Fwd: Re: New Python bindings

[Brian Granger]

On Mon, Feb 15, 2010 at 9:51 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> Brian,
>
>> I will add a copy keyword argument to the send method and set the
>> default to True.
>> If False is set, I will use the dealloc. function that mucks with the
>> GIL and refcount.
>> But the default will be to copy.
>
> GIL requires true mutex-like behaviour, ie. cache synchronisation between
> CPU cores, right?

I am not familiar with how the GIL is implemented, but I know it is
relatively slow.
I can also do some tests once I get both ways working (shouldn't be much work).

> If so, our measurements shows that copying is relatively cheap as compared
> to cache synchronisation. Thus, it makes sense to use GIL only for very
> large messages (several MB).

Yes, I don't expect the non-copy version to be faster until you get to
very large messages.

> As for the API, my suggestion would be to allow changing the behavior using
> a socket option rather than changing the signature of the send function.
> That way people don't have to care about the issue unless they have extreme
> latency requirements.

I think it would be nice though to have the option to use the two
version on a per send basis.
Maybe most of the send an app will do are small and should use the
copy version, but a few could
be really big where it makes a difference.  Plus, the new sig will not
require the user to know about
the options:

def send(msg, flags=0, copy=True)

But if you think that API compat. in send is important I can make it
an option to the Socket constructor or
setsockopt.

Cheers,

Brian

> Martin
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com