• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 101,  comments - 57,  trackbacks - 0

            source: http://bugs.python.org/issue5162

            classificationTitle: multiprocessing cannot spawn child from a Windows service  
            Type: behavior Stage: test needed
            Components: Library (Lib) Versions: Python 2.6
            processStatus: open Resolution: 
            Dependencies:   Superseder: 
            Assigned To: jnoller  Nosy List:  jnoller, orlenko (2) 
            Priority:  normal Keywords patch
             
            Created on 2009-02-06 02:00 by orlenko, last changed 2009-03-29 15:44 by jnoller.

            Files
            File name Uploaded Description Edit Remove
            forking-patch  orlenko, 2009-02-06 02:00  Patch of the forking module  
            Messages (1)
            msg81247 - (view) Author: Volodymyr Orlenko (orlenko) Date: 2009-02-06 02:00 
            I think I've found a small bug with multiprocessing package on
            Windows. If you try to start a multiprocessing.Process from a Python-
            based Windows service, the child process will fail to run. When
            running the parent process as a regular Python program, everything
            works as expected.
            I've tracked the problem down to how main_path is prepared in
            multiprocessing.forking.get_preparation_data() (lines 370-377):
            def get_preparation_data(name):
                [...skipped a few lines...]
                if not WINEXE:
                    main_path = getattr(sys.modules['__main__'], '__file__', None)
                    if not main_path and sys.argv[0] not in ('', '-c'):
                        main_path = sys.argv[0]
                    if main_path is not None:
                        if not os.path.isabs(main_path) and \
                                                  process.ORIGINAL_DIR is not
            None:
                            main_path = os.path.join(process.ORIGINAL_DIR,
            main_path)
                        d['main_path'] = os.path.normpath(main_path)
                return d
            When the program is running as a Windows service, but is not packaged
            into a single executable, main_path will become the path to the
            service executable (typically, pythonservice.exe). When this data
            makes it to the child process, the prepare() function will treat
            main_path as a path to a python module, and will try to import it.
            This causes it to fail.
            My quick-and-dirty solution was to check in get_preparation_data() if
            main_path ends with '.exe', and if it does, to not pass it at all.
            This solves the problem in my case, but perhaps there's a better way
            to fix this? Here is my version of get_preparation_data():
            def get_preparation_data(name):
                '''
                Return info about parent needed by child to unpickle process
            object
                '''
                from .util import _logger, _log_to_stderr
                d = dict(
                    name=name,
                    sys_path=sys.path,
                    sys_argv=sys.argv,
                    log_to_stderr=_log_to_stderr,
                    orig_dir=process.ORIGINAL_DIR,
                    authkey=process.current_process().authkey,
                    )
                if _logger is not None:
                    d['log_level'] = _logger.getEffectiveLevel()
                if not WINEXE:
                    main_path = getattr(sys.modules['__main__'], '__file__', None)
                    if not main_path and sys.argv[0] not in ('', '-c'):
                        main_path = sys.argv[0]
                    if main_path is not None:
                        if not os.path.isabs(main_path) and \
                                                  process.ORIGINAL_DIR is not
            None:
                            main_path = os.path.join(process.ORIGINAL_DIR,
            main_path)
                        if not main_path.endswith('.exe'):
                            d['main_path'] = os.path.normpath(main_path)
                return d

            posted on 2010-01-27 17:51 margin 閱讀(256) 評論(0)  編輯 收藏 引用 所屬分類: Pathon
            <2025年6月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            293012345

            常用鏈接

            留言簿

            隨筆檔案

            文章分類

            文章檔案

            收藏夾

            常去的壇子

            • CVC電腦病毒論壇
            • 很多人說我是AV,我告訴他們:別瞧不起人,我們也能創造價值
            • 安全焦點
            • 黑客聚集的地方,一般是好酒最多的地方...
            • 看雪論壇
            • 國內最強的加密解密論壇,成醉其中經常夜不歸宿
            • 驅動開發論壇
            • 厭倦了啤的朋友們,來我們來整點白的...痛痛快快的BSOD也好過隔鞋瘙癢!

            我的朋友

            • Sen的blog
            • IDE方面資深的受害者...經常為一個變量的定義找不著北的痛苦程序員(深表同情)
            • 老羅的blog
            • 良師益友,千年水牛,引擎猛男,分析怪獸,墨鏡酷哥,臺球高手....

            搜索

            •  

            最新評論

            国产成人精品久久亚洲| 韩国三级中文字幕hd久久精品| 国产精品久久新婚兰兰| 怡红院日本一道日本久久| 日本三级久久网| 久久久久久综合网天天| 69久久精品无码一区二区| 午夜精品久久久久久影视777| 国产成人无码精品久久久性色 | 久久国产精品99精品国产987| 国产精品伊人久久伊人电影| 99精品久久久久久久婷婷| 91久久精品国产免费直播| 伊人久久综合精品无码AV专区| 一本伊大人香蕉久久网手机| 午夜不卡久久精品无码免费| 性做久久久久久久久久久| WWW婷婷AV久久久影片| A级毛片无码久久精品免费| 久久久久亚洲AV无码去区首| 国产精品对白刺激久久久| 超级碰碰碰碰97久久久久| 国产视频久久| 99热都是精品久久久久久| 91精品国产综合久久久久久| 久久精品99久久香蕉国产色戒 | 中文字幕无码免费久久| 精品久久久久一区二区三区| 久久99精品国产99久久| 久久综合精品国产二区无码| 一日本道伊人久久综合影| 亚洲国产综合久久天堂 | 久久精品国产99久久久香蕉| 久久亚洲欧美日本精品| 久久99精品国产自在现线小黄鸭| 久久久精品人妻一区二区三区四| 日韩精品久久久肉伦网站| 亚洲AV日韩精品久久久久久| 国产激情久久久久久熟女老人| 蜜臀久久99精品久久久久久小说 | 久久丫精品国产亚洲av|