On Mon, Aug 29, 2011 at 8:42 PM, Jesse Noller wrote:
> On Mon, Aug 29, 2011 at 1:22 PM, Antoine Pitrou wrote:
>>
>> That sanitization is generally useful, though. For example if you want
>> to use any I/O after a fork().
>
> Oh! I don't disagree; I'm just against the removal of the ability to
> m
On Mon, Aug 29, 2011 at 8:16 PM, Antoine Pitrou wrote:
>
> On Mon, 29 Aug 2011 13:03:53 -0400 Jesse Noller wrote:
> >
> > Yes; but spawning and forking are both slow to begin with - it's
> > documented (I hope heavily enough) that you should spawn
> > multiprocessing children early, and keep them
Another face of the discussion is about whether to deprecate the mixing of
the threading and processing modules and what to do about the
multiprocessing module which is implemented with worker threads.
On Tue, Aug 23, 2011 at 11:29 PM, Antoine Pitrou wrote:
> Le mardi 23 août 2011 à 22:07 +0200
Hi all,
Please consider this invitation to stick your head into an interesting
problem:
http://bugs.python.org/issue6721
Nir
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
I take "...running off with the good stuff and selling it for profit" to
mean "creating derivative work and commercializing it as proprietary code"
which you can not do with GPL licensed code. Also, while the GPL does not
prevent selling copies for profit it does not make it very practical either.
I would like to restart this thread with 2 notes from the lively discussion:
a) Issue 7946 (and this discussion?) concerns Python 3.2
b) The GIL problems are not specific to OSX. The old and new GIL misbehave
on GNU/Linux and Windows too.
[Putting on anti-frying-pan helmet]
Nir
_
Hi all,
Here is a second (last?) attempt at getting traction on fixing the GIL (is
it broken?) with BFS (WTF?).
So don't be shy (don't be too rude either) since ignoring counts as down
voting.
Relevant Python issue: http://bugs.python.org/issue7946
*Bottom line first*
I submitted an implementa
happen. :)
>
> -peter
>
>
>
> On 4/12/10 3:36 PM, "Nir Aides" wrote:
>
> Please describe clearly a step by step scenario in which that code will
> fail.
>
>
> On Mon, Apr 12, 2010 at 10:25 PM, Peter Portante <
> peter.a.porta...@gmail.com> wro
> keep the code as is, call me when you need a life guard to help debug
> mystifying behaviors. ;) -peter
>
>
>
> On 4/12/10 3:17 PM, "Nir Aides" wrote:
>
> The loop-less wait is similar to the one in new GIL. It is used to force a
> switch to next thread i
ed_wait(tstate, timestamp);
> +timestamp = get_timestamp();
> +}
>
> You might want to avoid the call to reset the condition variable if the
> predicate is already False.
>
> -peter
>
>
> On 4/12/10 8:12 AM, "Nir Aides" wrote:
>
> Hi Pet
et_timestamp();
> +}
>
> You might want to avoid the call to reset the condition variable if the
> predicate is already False.
>
> -peter
>
>
>
> On 4/12/10 8:12 AM, "Nir Aides" wrote:
>
> Hi Peter,
>
> There is no need for a loo
their
> implementations, must be sound.
>
> -peter
>
>
>
> On 4/11/10 6:50 PM, "Nir Aides" < n...@winpdb.org> wrote:
>
> Hello all,
>
> I would like to kick this discussion back to life with a simplified
> implementation of the BFS scheduler, design
Hello all,
I would like to kick this discussion back to life with a simplified
implementation of the BFS scheduler, designed by the Linux kernel hacker Con
Kolivas: http://ck.kolivas.org/patches/bfs/sched-BFS.txt
I submitted bfs.patch at http://bugs.python.org/issue7946. It is work in
progress bu
ticks during countdown).
Remains to explore what can be done on other platforms.
Nir
2010/3/16 Nir Aides
> Hello Dave,
>
> The following documentation suggests ordering in Linux is not FIFO:
>
> http://www.opengroup.org/onlinepubs/95399/functions/pthread_cond_timedwait.html#t
Hello Dave,
The following documentation suggests ordering in Linux is not FIFO:
http://www.opengroup.org/onlinepubs/95399/functions/pthread_cond_timedwait.html#tag_03_518_08_06
"Threads waiting on mutexes and condition variables are selected to proceed
in an order dependent upon the scheduling
inline:
On Sun, Mar 14, 2010 at 3:54 PM, Peter Portante
wrote:
> On 3/14/10 7:31 AM, "Nir Aides" wrote:
>
> There are two possible problems with Dave's benchmark:
>
> 1) On my system setting TCP_NODELAY option on the accepted server socket
> changes results dra
There are two possible problems with Dave's benchmark:
1) On my system setting TCP_NODELAY option on the accepted server socket
changes results dramatically.
2) What category of socket servers is dave's spin() function intended to
simulate?
In a server which involves CPU intensive work in respons
Seems the problem under discussion is already taken care of in Python.
Possibly remains to verify that the logic described below does not possibly
generate deadlocks.
>From the Python docs: http://docs.python.org/c-api/init.html
"Another important thing to note about threads is their behaviour in
18 matches
Mail list logo
