On 9/7/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 9/7/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > A Signature object has the following structure attributes:
> >
> > > * name : str
> > > Name of the function. This is not fully qualified because
> > > function objects for methods d
On 9/7/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > A Signature object has the following structure attributes:
>
> > * name : str
> > Name of the function. This is not fully qualified because
> > function objects for methods do not know the class they are
> > contained within. This m
Trent> If some would find it useful, here is a snippet of code that
Trent> obfuscates email addresses for HTML as done by Markdown (a
Trent> text-to-html markup translator). It randomly encodes each
Trent> charater as a hex or decimal HTML entity (roughly 10% raw, 45%
Trent> he
> Well, one shouldn't be bothering with threads unless the user intends
> to create threads. So I think it's not kosher. Once threads are
> initialized, everything runs a tad slower because the GIL
> manipulations actually cost time (even if there are no other threads).
I think that doing it in _s
Well, one shouldn't be bothering with threads unless the user intends
to create threads. So I think it's not kosher. Once threads are
initialized, everything runs a tad slower because the GIL
manipulations actually cost time (even if there are no other threads).
On 9/7/07, Bill Janssen <[EMAIL PRO
> So what happens when someone loads the _ssl module, initializes the
> threads, and tries to use SSL? It's going to start failing again. I
Which turns out to be exactly what test_ssl.py does. I'm tempted
to have the _ssl module call PyEval_InitThreads(). Would that be kosher?
Bill
__
> #define SSL_ALLOW_THREADS {if (_ssl_locks != NULL) { Py_BEGIN_ALLOW_THREADS }}
> #define SSL_DISALLOW_THREADS {if (_ssl_locks != NULL) {
> Py_BEGIN_ALLOW_THREADS }}
I'd forgotten how convoluted Py_BEGIN_ALLOW_THREADS and
Py_END_ALLOW_THREADS were. Anyone have any other suggestions about
how to
Reading through the C API documentation, I find:
``This is done so that dynamically loaded extensions compiled with
thread support enabled can be loaded by an interpreter that was
compiled with disabled thread support.''
I've currently got the set-up-SSL-threading code in _ssl.c surrounded
by a "
> My analysis is that we need to add lock and unlock functions to the
> OpenSSL initialization code we currently use
Yep, this seems to fix the problem. I'm now able to re-enable
Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS, and still get a clean
run:
(gdb) run
Starting program: /local/python/t
David Goodger wrote:
> On 8/20/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> I believe email addresses are automatically obfuscated as part of the
>> HTML generation process, but one of the PEP editors can correct me if
>> I am wrong.
>
> Yes, email addresses are obfuscated in PEPs.
>
> For exam
> I'm seeing a number of malloc (actully, free) errors, now that I'm
> pounding on the OpenSSL server/client setup with lots of server
> threads and client threads. They all look like either
The issue seems to be that we assume OpenSSL is thread-safe (that is,
we call Py_BEGIN_ALLOW_THREADS / Py_
I'm seeing a number of malloc (actully, free) errors, now that I'm
pounding on the OpenSSL server/client setup with lots of server
threads and client threads. They all look like either
(gdb) bt
#0 0x9010b807 in malloc_printf ()
#1 0x900058ad in szone_free ()
#2 0x90005588 in free ()
#3 0x9194
> Is this a --with-pydebug build? If not, it should be.
Yes.
> If that still does not give insights, I usually try valgrind
> (although usually with little success).
Actually, Google is your friend here. The message in malloc is
misleading; set a breakpoint in malloc_printf instead.
Bill
_
Brett Cannon wrote:
> A Signature object has the following structure attributes:
> * name : str
> Name of the function. This is not fully qualified because
> function objects for methods do not know the class they are
> contained within. This makes functions and methods
> indist
> I've been expanding the SSL test suite, and found something like this
> cropping up, not always, but maybe 30% of the time. So I run it under
> gdb, but the "szone_error" breakpoint never gets hit. Any other
> malloc debugging tips I should know about?
Is this a --with-pydebug build? If not, i
I think there's a way to enable heavier malloc debugging than the
normal --with-pydebug. You'll have to enable it manually by editing
Python.h I believe. Though it may already be on if you define
Py_DEBUG. (Is WITH_PYMALLOC always on?) Ther may also be a libmalloc
that enables heavier debugging; th
I've been expanding the SSL test suite, and found something like this
cropping up, not always, but maybe 30% of the time. So I run it under
gdb, but the "szone_error" breakpoint never gets hit. Any other
malloc debugging tips I should know about?
(gdb) info break
Num Type Disp Enb Addr
17 matches
Mail list logo
