date:20060417

[Python-Dev] Summer of Code preparation

2006-04-17 Thread Neal Norwitz

We've only got a short time to get setup for Google's Summer of Code. 
We need to start identifying mentors and collecting ideas for students
to implement.  We have the SimpleTodo list
(http://wiki.python.org/moin/SimpleTodo), but nothing on the SoC page
yet (http://wiki.python.org/moin/SummerOfCode).

I can help manage the process from inside Google, but I need help
gathering mentors and ideas.  I'm not certain of the process, but if
you are interested in being a mentor, send me an email.  I will try to
find all the necessary info and post here again tomorrow.  Pass the
word!  I hope all mentors from last year will return again this year.

Can someone take ownership of drumming up mentors and ideas?  We also
need to spread the word to c.l.p and beyond.

Thanks,
n
___
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] Py_Finalize does not release all memory, not even closely

2006-04-17 Thread Martin v. Löwis

Tim Peters wrote:
 Putting a collection call inside an initialize/finalize loop isn't
 doing it late, it's doing it early.  If we can't collect cyclic trash
 after Py_Initialize(), that would be a showstopper for apps embedding
 Python in a loop!  There's either nothing to fear here, or Python
 has a very bad bug.

Right. I did that, and it collects 308 objects after the first call
in the second round of Py_Initialize/Py_Finalize, and then no
additional objects.

However, I don't think that helps much: Py_Finalize will call
PyGC_Collect(), anyway, and before any counts are made.

 Are you thinking of this comment?:

Yes; I was assuming you suggested to enable that block of code.

 I wrote that, and think it's pretty clear:  after PyImport_Cleanup(),
 so little of the interpreter still exists that _any_ problem while
 running Python code has a way of turning into a fatal problem.

Right. I still haven't tried it, but it might be that, after a plain
Py_Initialize/Py_Finalize sequence, no such problems will occur,
and that it would be safe to call it in this specific case.

 Could you check in the code you're using?

I had to modify code in ways that shouldn't be checked in, e.g.
by putting API calls into _Py_PrintReferenceAddresses, even
though the comment says it does't call any API. When I get to
clean this up, I'll check it in.

With some debugging, I now found a leak that contributes
to quite some of these garbage objects: Each round of
Py_Initialize/Py_Finalize will leave a CodecInfo type
behind. I think it comes from this block of code

/* Note that as of Python 2.2, heap-allocated type objects
 * can go away, but this code requires that they stay alive
 * until program exit.  That's why we're careful with
 * refcounts here.  type_list gets a new reference to tp,
 * while ownership of the reference type_list used to hold
 * (if any) was transferred to tp-tp_next in the line above.
 * tp is thus effectively immortal after this.
 */
Py_INCREF(tp);

so that this leak would only exist if COUNT_ALLOCS is defined.

I would guess that even more of the leaking type objects (16 per
round) can be attributed to this. This completely obstructs
measurements, and could well explain why the number of leaked
objects is so much higher when COUNT_ALLOCS is defined. OTOH,
I can see why this code requires that they stay alive.

Any ideas on how to solve this dilemma? Perhaps the type_list
could be a list of weak references, so that the types do have
a chance to go away when the last instance disappears?

Regards,
Martin
___
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] windows buildbot failures

2006-04-17 Thread Martin v. Löwis

Neal Norwitz wrote:
If the patch won't fix the problem, is there something else we can do
to ensure the python DLL is no longer used regardless of whether the
previous test passed or not?

Rebooting the machine will help, and might be the only cure.
It's Windows, after all :-(

Of course, we shouldn't do that, and even if it was ok to reboot
remotely, the buildbot likely wouldn't come back automatically.

If we can get the process handle, can we
can subprocess.TerminateProcess()?

You get the process handle either from CreateProcess (which buildbot
did, so we can't get the handle), or from OpenProcess. For
OpenProcess, we need a process id. One way to get that is
through Process32First/Process32Next. These would provide the
executable path, so it should be easy to find out which one
is a python_d.exe binary.

None of these functions is exposed through subprocess,
so this is no option. In addition, I believe that buildbot
*tries* to use TerminateProcess. The code is twisted, though,
so it is hard to tell what actually happens.

Of course, it would be possible to do this all in VisualBasic,
so we could check in a vbscript file, similar to the one in

http://support.microsoft.com/kb/q187913/

OTOH, we could just as well check in an executable that
does all that, e.g. like the one in

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/base/enumerating_all_modules_for_a_process.asp

Regards,
Martin
___
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

40 matches

Mail list logo