sturlamolden wrote:
On Jun 5, 11:02 am, pataphor <[EMAIL PROTECTED]> wrote:
This is probably not very central to the main intention of your post,
but I see a terminology problem coming up here. It is possible for
python objects to share a reference to some other object. This has
nothing to do w
On Jun 5, 11:02 am, pataphor <[EMAIL PROTECTED]> wrote:
> This is probably not very central to the main intention of your post,
> but I see a terminology problem coming up here. It is possible for
> python objects to share a reference to some other object. This has
> nothing to do with threads or
In article <877a5774-d3cc-49d3-bb64-5cab8505a419
@m3g2000hsc.googlegroups.com>, [EMAIL PROTECTED] says...
> I don't see pyprocessing as a drop-in replacement for the threading
> module. Multi-threading and multi-processing code tend to be
> different, unless something like mutable objects in share
Christian Heimes wrote:
> Can you provide a C implementation that compiles under VS 2008? Python
> 2.6 and 3.0 are using my new VS 2008 build system and we have dropped
> support for 9x, ME and NT4. If you can provide us with an
> implementation we *might* consider using it.
You'd have to at leas
sturlamolden schrieb:
> There is a well known C++ implementation of cow-fork on Windows, which
> I have slightly modified and ported to C. But as the new WDK (Windows
> driver kit) headers are full of syntax errors, the compiler choke on
> it. :( I am seriously considering re-implementing the whole
On Jun 4, 11:29 pm, Paul Boddie <[EMAIL PROTECTED]> wrote:
> tested the executable on Windows. COW (copy-on-write, for those still
> thinking that we're talking about dairy products) would be pretty
> desirable if it's feasible, though.
There is a well known C++ implementation of cow-fork on Wind
On 4 Jun, 20:06, sturlamolden <[EMAIL PROTECTED]> wrote:
>
> Even a non-COWfork
> would be preferred. I will strongly suggest something is done to add
> support for os.fork to Python on Windows. Either create a full cow
> fork using ZwCreateProces
