Re: [Python-Dev] Possible platforms to drop in 2.6

[Andrew MacIntyre]

[EMAIL PROTECTED] wrote:
> Brett> So, here are the platforms I figured we should drop:
> 
> ...
> Brett> * OS/2
> 
> I'm pretty sure Andrew MacIntyre is still maintaining the OS/2+EMX port:
> 
> http://members.pcug.org.au/~andymac/python.html

I am, although I haven't managed a binary release of 2.5 yet (should be
in a few days).

If its just the os2vacpp subdirectory in PC/ that is being discussed,
that could go for 2.6.

It will be a fair amount of work to disentangle the defines used for the
2 ports - a fair bit of the platform specific code is shared, but with 
compiler related differences.  I would suggest more trouble than its
worth for 2.6, but I could work on it.

Of course, if the project management decide that even the EMX support
should be removed from the official tree - so be it; I will just have
to maintain the port outside the official tree.

-- 
-
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: [EMAIL PROTECTED]  (pref) | Snail: PO Box 370
[EMAIL PROTECTED] (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/   |Australia
___
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] Non-blocking (asynchronous) timer without thread?

[tomer filiba]

> The main goal is to prevent threads overhead and problems with race
> conditions and deadlocks.

check out stackless python -- http://www.stackless.com/


-tomer
___
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] Possible platforms to drop in 2.6

[Guido van Rossum]

On 12/23/06, Andrew MacIntyre <[EMAIL PROTECTED]> wrote:
> Of course, if the project management decide that even the EMX support
> should be removed from the official tree - so be it; I will just have
> to maintain the port outside the official tree.

I don't think that's the objective. In general we don't mind if a
resonable amount of platform-specific stuff sprinkled over the source
tree, *as long as there is someone to maintain it*. Such code tends to
break each time a major feature is added or modified, which is pretty
much every release. If no-one is there to repair these, the platform
code becomes useless, and *then* it becomes a matter of deciding to
clean up unneeded hacks, to simplify future maintenance. We want to
keep a reasonable balance where the code is reasonably clean and
doesn't contain pockets of dead code that nobody understands, but if
someone is actively maintaining a port we'd like to support them by
minimizing the effort it takes for them to port each new Python
version.

It seems that you're on the ball, so we can keep your changes. We
would appreciate it if you could point out things you no longer need
(I understand the os2vacpp directory might be one of these?).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Non-blocking (asynchronous) timer without thread?

[Josiah Carlson]

Evgeniy Khramtsov <[EMAIL PROTECTED]> wrote:
> Mike Klaas пишет:
> 
> > I'm not sure how having python execute code at an arbitrary time would
> > _reduce_ race conditions and/or deadlocks. And if you want to make it
> > safe by executing code that shares no variables or resources, then it
> > is no less safe to use threads, due to the GIL.
> >
> Ok. And what about a huge thread overhead? Just try to start 10-50k 
> threading timers :)

That is a foolish task in any language, and is why heap-based schedulers
exist.  You can use a Queue as synchronization between timer producers
and the scheduler, and another Queue as synchronization between the
scheduler and your threadpool (5-10 should be fine and have minimal
overhead).

Also 10-50k threads, in just about any language or runtime (except
using C in solaris on SPARC, which can handle that pretty well), is way
too much to handle.  With thread stack sizes as they are, I wouldn't be
surprised if you were running into the limit of your main memory size,
and you would certianly be destroying the effectiveness of most caches.

One thing that came to mind is that perhaps the "overhead" you are
experiencing when using threads isn't context switch time, but is the
fact that you have thousands of threads waiting on signals from the
OS to continue, or even that Python switches threads after a certain
number of bytecodes have been interpreted (if they are not waiting on
wait syscalls). Python 2.5 sets the interval at 100 bytecodes (see
sys.[get|set]checkinterval()), which is either 1 million or 5 million
bytecodes with your load of 10k-50k.  For most operations, this would be
a palpable delay of up to a couple seconds before a thread gets back to
doing what it was doing.

Seriously, threadpool with a scheduler.


 - Josiah

___
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] Python and the Linux Standard Base (LSB)

[Tony Nelson]

At 8:42 PM +0100 12/2/06, Martin v. Löwis wrote:
>Jan Claeys schrieb:
>> Like I said, it's possible to split Python without making things
>> complicated for newbies.
>
>You may have that said, but I don't believe its truth. For example,
>most distributions won't include Tkinter in the "standard" Python
>installation: Tkinter depends on _tkinter depends on Tk depends on
>X11 client libraries. Since distributors want to make X11 client
>libraries optional, they exclude Tkinter. So people wonder why
>they can't run Tkinter applications (search comp.lang.python for
>proof that people wonder about precisely that).
>
>I don't think the current packaging tools can solve this newbie
>problem. It might be solvable if installation of X11 libraries
>would imply installation of Tcl, Tk, and Tkinter: people running
>X (i.e. most desktop users) would see Tkinter installed, yet
>it would be possible to omit Tkinter.

Given the current packaging tools, could Python have stub modules for such
things that would just throw a useful exception giving the name of the
required package?  Perhaps if Python just had an example of such a stub
(and Tkinter comes to mind), packagers would customize it and make any
others they needed?
-- 

TonyN.:'The Great Writ 
  '  is no more. 
___
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] Possible platforms to drop in 2.6

[Anthony Baxter]

On Sunday 24 December 2006 00:19, Andrew MacIntyre wrote:
> Of course, if the project management decide that even the EMX
> support should be removed from the official tree - so be it; I
> will just have to maintain the port outside the official tree.

I feel that so long as there's an active maintainer for a port, it 
can and should stay. It's the older systems where we have no 
maintainer and no way to check if it's still working that are the  
problem.
___
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