[Scons-dev] Fix async subprocess execution with proper handling of std* streams

anatoly techtonik techtonik at gmail.com
Tue Feb 25 02:52:50 EST 2014


That's cool. The document is a very good starting point. To me this
streams framework is a very useful component that should be merged
into provisional packages of Python standard library. I still need to
find time to read it thoroughly to adapt to what I know.

On Mon, Feb 24, 2014 at 9:57 PM, Kenny, Jason L <jason.l.kenny at intel.com> wrote:

> Hi Anatoly,

>

> Attached is a word document with the overview of the deign I have with thoughts on some good and bad of it. Hopefully I proofed the document enough, document writing is not my strong suit. Anyways let me know if you have any other questions, etc.. on the design.

>

> Eugene who has been helping with Parts work inside thinks he fixed a Scons/Parts rebuild issues we have been dealing with. I testing it out, if it looks good I will push this drop in a few days.

>

> Thanks for looking at this!

> Jason

>

> -----Original Message-----

> From: scons-dev-bounces at scons.org [mailto:scons-dev-bounces at scons.org] On Behalf Of anatoly techtonik

> Sent: Tuesday, February 18, 2014 10:35 AM

> To: SCons developer list

> Subject: Re: [Scons-dev] Fix async subprocess execution with proper handling of std* streams

>

> Thanks. That would be great. ;)

>

> On Tue, Feb 18, 2014 at 5:21 PM, Kenny, Jason L <jason.l.kenny at intel.com> wrote:

>> I will get it pushed… life getting in the way.

>>

>>

>>

>> From: scons-dev-bounces at scons.org [mailto:scons-dev-bounces at scons.org]

>> On Behalf Of Eugene Leskinen

>> Sent: Tuesday, February 18, 2014 7:03 AM

>> To: SCons developer list

>> Subject: Re: [Scons-dev] Fix async subprocess execution with proper

>> handling of std* streams

>>

>>

>>

>> Hi Anatoly,

>>

>>

>>

>> The code supporting I/O redirection in Parts is located in

>> parts/part_logger.py file. Look at

>> http://parts.tigris.org/source/browse/parts/trunk/parts/parts/part_log

>> ger.py?revision=486&view=markup

>>

>>

>>

>> The code uses Python threading module to create threads for each

>> stream and then runs a loop in every thready like your code does:

>>

>>

>>

>> line = ' '

>>

>> try:

>>

>> while line:

>>

>> line = self.pipein.readline()

>>

>> if line:

>>

>> self.output.WriteStream(self.taskId,

>> self.streamId,

>> line)

>>

>> except:

>>

>> # There was an error... that shouldn't happen, but still it did.

>> So we report it

>>

>> # to the caller and close our pipe end so that spawned

>> program won't block

>>

>> self.error = traceback.format_exc()

>>

>> self.pipein.close()

>>

>> self.pipein = None

>>

>>

>>

>> Please note that public repo is a bit out-of-date. I hope Jason will

>> find time to pull up-to-date version from Intel internal repository.

>>

>>

>>

>> 2014-02-18 16:30 GMT+04:00 anatoly techtonik <techtonik at gmail.com>:

>>

>> On Wed, Feb 12, 2014 at 6:25 PM, Kenny, Jason L

>> <jason.l.kenny at intel.com>

>> wrote:

>>>> Fix async subprocess execution with proper handling of std* streams.

>>>

>>> So I fixed the issue with output in Parts. I not saying it could not

>>> be clean up some more. However it solves the output issues, and adds

>>> coloring ( which seems to need some fixing in certain cases.. ie mac

>>> mostly) and logging support. It might not be too hard for someone to

>>> move the code over to SCons and integrated its usage into SCons.

>>

>> Do you have, by any chance a description of output issues?

>> It seems that I've lost my list during the last Windows partition crash.

>>

>> Also, can you pinpoint the parts in Parts that are relevant to the issues?

>> I may have time to port them over to SCons.

>>

>> My approach

>> https://bitbucket.org/techtonik/absub

>> to make subprocess asynchronous by moving processing of input/output

>> streams into separate threads. I don't remember why, but the work

>> stalled. I remember there was some kind of error that I was not able

>> to debug due to distributed nature of the process. I needed to write

>> more tests for that, but it is either I run out of time, multithreaded

>> tests were complicated or I just had an annual Windows filesystem

>> crash.

>>

>> Now I am thinking about replacing concept of input/output streams with

>> the concept of channel, which is a queue of strings with limited size.

>> The queue can be rotated to become unlimited. Can be synchronous to

>> wait (block) until messages are read if the queue is full. This may

>> help to clear confusion around all that input output streams handling,

>> pipes and descriptor inheritances.

>>

>> --

>> anatoly t.

>> _______________________________________________

>> Scons-dev mailing list

>> Scons-dev at scons.org

>> http://two.pairlist.net/mailman/listinfo/scons-dev

>>

>>

>>

>>

>>

>> --

>> Regards,

>> Eugene Leskinen

>>

>>

>> _______________________________________________

>> Scons-dev mailing list

>> Scons-dev at scons.org

>> http://two.pairlist.net/mailman/listinfo/scons-dev

>>

>

>

>

> --

> anatoly t.

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev

>

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev

>




--
anatoly t.


More information about the Scons-dev mailing list