On Sun, 24 Feb 2013 10:01:12 -0500, Lars T. Kyllingstad <public@kyllingen.net> wrote:


> Wait for all processes:
>
> This would certainly be convenient, and it is simple to implement.  It would require a static __gshared Pid[int] of all processes created by spawnProcess(), and we'd simply call wait() on all of those.

Waiting for ALL processes in an array should be a simple matter of some algorithm call.

I didn't see this specific request.  I think the request was to wait for any process in a specific subset to complete.  And then of course, the "wait for any process."  Either of these is possible similar to how core.thread keeps track of all threads, we could simply ignore any child exits that we didn't manage.  And I think it's worth implementing at some point (this is not an easy problem to solve correctly), but not for this release.

-Steve

On Sunday, 24 February 2013 at 15:37:10 UTC, Steven Schveighoffer wrote:
> On Sun, 24 Feb 2013 10:01:12 -0500, Lars T. Kyllingstad <public@kyllingen.net> wrote:
>
>
>> Wait for all processes:
>>
>> This would certainly be convenient, and it is simple to implement.  It would require a static __gshared Pid[int] of all processes created by spawnProcess(), and we'd simply call wait() on all of those.
>
> Waiting for ALL processes in an array should be a simple matter of some algorithm call.
>
> I didn't see this specific request.  I think the request was to wait for any process in a specific subset to complete.  And then of course, the "wait for any process."

Yeah, maybe nobody requested it, and it was just a subconscious personal desire of mine.  I actually had a waitAll() function in my very first draft, as you may recall.  It was only implemented for POSIX, and it had all the problems mentioned here wrt. processes not created by spawnProcess(), so you (rightly) convinced me to remove it.

I even had a waitAny() function in there, which you also (again, rightly) didn't take kindly to. :)


> Either of these is possible similar to how core.thread keeps track of all threads, we could simply ignore any child exits that we didn't manage.  And I think it's worth implementing at some point (this is not an easy problem to solve correctly), but not for this release.

I agree, this will be difficult or impossible on POSIX.  Calling wait() and then ignoring the processes we don't care about won't do, because then we've ruined the chance for other code to call wait() on those processes.

Lars

On Sun, 24 Feb 2013 10:53:48 -0500, Lars T. Kyllingstad <public@kyllingen.net> wrote:

> On Sunday, 24 February 2013 at 15:37:10 UTC, Steven Schveighoffer wrote:

>
>> Either of these is possible similar to how core.thread keeps track of all threads, we could simply ignore any child exits that we didn't manage.  And I think it's worth implementing at some point (this is not an easy problem to solve correctly), but not for this release.
>
> I agree, this will be difficult or impossible on POSIX.  Calling wait() and then ignoring the processes we don't care about won't do, because then we've ruined the chance for other code to call wait() on those processes.

I think if we have this feature, there needs to be a big fat warning not to start child processes except through this library.  We could provide a hook to call when an unknown child exits...

-Steve

On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T. Kyllingstad wrote:
>
> Pull request:
> https://github.com/D-Programming-Language/phobos/pull/1151
>
> Code:
> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>
> Documentation:
> http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html

Ok, a new version with non-blocking wait is up.

Lars

24-Feb-2013 21:41, Lars T. Kyllingstad пишет:
> On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T. Kyllingstad wrote:
>>
>> Pull request:
>> https://github.com/D-Programming-Language/phobos/pull/1151
>>
>> Code:
>> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>>
>> Documentation:
>> http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html
>>
>
> Ok, a new version with non-blocking wait is up.

asyncWait would be less verbose :)

Also how about returning a "Future" object that you may block on some loong time later?


-- 
Dmitry Olshansky

On Sun, 24 Feb 2013 03:46:32 +0100, Andrej Mitrovic wrote:

> > Ah but how can you guarantee we won't ever need a 3rd rewrite? It's
> always possible we might need one in the future.

I think you want to guarantee that it CAN be re-written, because existing code always becomes crufty, and even less wise as time goes on, as new requirements become obvious.

> It's also a problem if we have to start remembering version numbers for each module we import. E.g.:
> 
> import std.process2;
> import std.xml; // oops, did I mean xml2 maybe?
> import std.signals2;
> 
> It's going to be annoying using Phobos like that. I was going to suggest using version flags, but even that could be annoying, although that feature was practically invented for this kind of problem.

Agreed.  But I think the problem is that we're talking about changing individual modules' versions, within what should be a stable D API.

I would much rather see something like D1 = Phobos1, D2 = Phobos2, and some flag at the top of a file, like @d_version(2), to say which version your code expects/requires.

The compiler could then say one of:

* OK, I'm version 3, but I'll give you the v2 phobos --- probably through library code like "version(>= d3) { ... } else { ... }"

* Sorry, I'm version 2, and you need version 3.  You need a newer compiler.

* Potentially, it could say, "Sorry, I'm D version 6, and only support versions since D4.  To compile D1-D3 code, you need an older compiler." But I don't think this would be wise.


Do D compilers currently warn about using deprecated features?  If not, that would be a useful addition from this kind of version specification, too.


The main benefit of this is that, within D2, there would be a truly STABLE API.  You'd know whether you should go with Phobos's built-in stream library, say, or some third-party library, because there wouldn't be a new rewrite coming next week.  Either you're writing for D2, or you're writing for D3.  If D2 doesn't have it, then you find a third- party lib that does.  If D3 has it, and you want that, then you check out the bleeding edge D3 compiler / libs, and hope it doesn't blow up.


-- 
Lee

24-Feb-2013 22:05, Dmitry Olshansky пишет:
> 24-Feb-2013 21:41, Lars T. Kyllingstad пишет:
>> On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T. Kyllingstad wrote:
>>>
>>> Pull request:
>>> https://github.com/D-Programming-Language/phobos/pull/1151
>>>
>>> Code:
>>> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>>>
>>> Documentation:
>>> http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html
>>>
>>>
>>
>> Ok, a new version with non-blocking wait is up.
>
> asyncWait would be less verbose :)
>

> Also how about returning a "Future" object that you may block on some
> loong time later?

Oh wait, the Pid itself + blocking wait fits the bill. Then all is fine as is, sorry for the noise.



-- 
Dmitry Olshansky

On Sunday, 24 February 2013 at 18:05:14 UTC, Dmitry Olshansky wrote:
> 24-Feb-2013 21:41, Lars T. Kyllingstad пишет:
>> On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T. Kyllingstad wrote:
>>>
>>> Pull request:
>>> https://github.com/D-Programming-Language/phobos/pull/1151
>>>
>>> Code:
>>> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>>>
>>> Documentation:
>>> http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html
>>>
>>
>> Ok, a new version with non-blocking wait is up.
>
> asyncWait would be less verbose :)

To me, "asynchronous" implies that something is going on in the background that will produce a result in the future.  That is not what happens here.

I agree that nonBlockingWait() is less than ideal, though, mainly because it is an oxymoron. :)  I considered "status", "isAlive", etc., but I think it is important to emphasise the fact that if the process *has* terminated, nonBlockingWait() has the same, perhaps non-obvious, effects as wait():

On POSIX, it makes the OS clean up after the process.
On Windows, it closes the process handle.
On all platforms, it invalidates the processID and osHandle properties of the Pid object.

If you or anyone else have a better suggestion, I'm all ears.

Lars

> To me, "asynchronous" implies that something is going on in the background that will produce a result in the future.  That is not what happens here.
>
> I agree that nonBlockingWait() is less than ideal, though, mainly because it is an oxymoron. :)  I considered "status", "isAlive", etc., but I think it is important to emphasise the fact that if the process *has* terminated, nonBlockingWait() has the same, perhaps non-obvious, effects as wait():
>
> On POSIX, it makes the OS clean up after the process.
> On Windows, it closes the process handle.
> On all platforms, it invalidates the processID and osHandle properties of the Pid object.
>
> If you or anyone else have a better suggestion, I'm all ears.
>
> Lars

Maybe tryWait?

24-Feb-2013 22:42, Lars T. Kyllingstad пишет:
> On Sunday, 24 February 2013 at 18:05:14 UTC, Dmitry Olshansky wrote:
>> 24-Feb-2013 21:41, Lars T. Kyllingstad пишет:
>>> On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T. Kyllingstad
>>> wrote:
>>>>
>>>> Pull request:
>>>> https://github.com/D-Programming-Language/phobos/pull/1151
>>>>
>>>> Code:
>>>> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>>>>
>>>> Documentation:
>>>> http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html
>>>>
>>>>
>>>
>>> Ok, a new version with non-blocking wait is up.
>>
>> asyncWait would be less verbose :)
>
> To me, "asynchronous" implies that something is going on in the
> background that will produce a result in the future.  That is not what
> happens here.
>
> I agree that nonBlockingWait() is less than ideal, though, mainly
> because it is an oxymoron. :)  I considered "status", "isAlive", etc.,
> but I think it is important to emphasise the fact that if the process
> *has* terminated, nonBlockingWait() has the same, perhaps non-obvious,
> effects as wait():
>

detach
or
detachProcess

maybe as a method on Pid struct.
Then there is no need to handle status codes etc.
> On POSIX, it makes the OS clean up after the process.
> On Windows, it closes the process handle.
> On all platforms, it invalidates the processID and osHandle properties
> of the Pid object.
>
> If you or anyone else have a better suggestion, I'm all ears.
>
> Lars


-- 
Dmitry Olshansky