[issue30018] multiprocessing.Pool garbles call stack for __new__

Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ _

[issue30018] multiprocessing.Pool garbles call stack for __new__

Charles McEachern added the comment: That seems to do it! Looks like the trick is to define __reduce__ to help out the serializer. Thanks! -- ___ Python tracker ___

[issue30018] multiprocessing.Pool garbles call stack for __new__

R. David Murray added the comment: I suspect you just need to add pickle support to your class. When I subclassed str in the email package, I found I needed to do that. I'd have to go through the docs again to remember how the code works, but you can take a look at the BaseHeader class in em

[issue30018] multiprocessing.Pool garbles call stack for __new__

Davin Potts added the comment: > I am unfortunately not at liberty to share the code I'm working on. I very much understand and am very thankful you took the time to create a simple example that you could share. Honestly, that's the reason I felt inspired to stop what I was doing to look at t

[issue30018] multiprocessing.Pool garbles call stack for __new__

Charles McEachern added the comment: This caused me several hours of misery yesterday, trying to isolate what was going wrong. I am unfortunately not at liberty to share the code I'm working on. The example on GitHub has the general thrust of it: my constructor was always called in a specifi

[issue30018] multiprocessing.Pool garbles call stack for __new__

Davin Potts added the comment: Expanding my above example to show how multiprocessing relates: >>> import multiprocessing >>> import os >>> class Floof(object): ... def __new__(cls): ... print("New via pid=%d" % os.getpid()) ... return object.__new__(cls) ... >>> os.getpid()

[issue30018] multiprocessing.Pool garbles call stack for __new__

Davin Potts added the comment: It looks like the first 'Called Foo.__new__' is being reported by the child (pool of 1) process and the second 'Called Foo.__new__' is being reported by the parent process. In multiprocessing, because objects are by default serialized using pickle, this may be c

[issue30018] multiprocessing.Pool garbles call stack for __new__

New submission from Charles McEachern: I'm calling the constructor of Foo, a subclass of str. Expected output: Called Foo.__new__ with args = ('TIMESTAMP', 'INPUT0') TIMESTAMP OUTPUT0 When I make the call using a multiprocessing.pool.ThreadPool, it works fine. But when I make the call using a