Re: Spawn support in pkgsrc tools - Google Summer of Code 2016

[Aleksej Saushev <asau%inbox.ru@localhost>]

  Hello,

Martin Husemann <martin%duskware.de@localhost> writes:

> On Sun, Mar 13, 2016 at 01:58:38AM +0000, Andreas Theodosiou wrote:
>> the tools mentioned in my original message. I will also spent time
>> reading code during the drafting of the proposal so perhaps the first
>> item can be allocated even less time.
>
> Oh, I didn't intend to urge you to cut down time estimates, I just
> wanted to point out that you should provide possible extensions.
> The time is hard to guess, as it highly depends on the source code of the
> tool you are converting - assuming you will be familiar with posix_spawn
> itself after the second or third tool.

>> As far as performance evaluation goes, after a discussion with Aleksej
>> it is my opinion that instead of writing tests, testing use case
>> scenarios such as the time taken to build a package, or a set of
>> packages would offer greater insight into the impact of the code
>> changes. At this point I would like to ask the prefered method of
>> evaluating execution time in NetBSD. Would a sh script that uses time(1)
>> and then logs the output suffice? Should a specific program be written?
>
> A few builds and time(1) should be good enough for this, no specific
> program needs to be written, but you need to think about what tests
> exactly you want to run (and check how stable the timings are ...)

Probably, it is useful to point explicitly that the stability of tests
like these is very subtle issue. It may demand a lot more work than
originally anticipated. ("Few" may easily grow to "few decades.")

>> Possible extensions could be implementing posix_spawn in system(3) and in
>> shells/bash.
>
> Good, maybe you can find a few more like that? popen(3) maybe?

Since we're talking about pkgsrc, I think, that it is useful to remind
that NetBSD is not the only operating system implementing posix_spawn.
This may give enough space to extend the scope.


-- 
HE CE3OH...