David,

    I agree with you failure might be misleading is some cases including
this one. It is a hard decision sometimes to pick between a failure and a
runtime error. Runtime errors are hard to ignore as you said, but in many
cases users want their programs to proceed and they want to be able to
handle the failure themselves instead of ending up with a crashed program.
The fork() example in IPL reveals a problem (kind of a problem) in the
example itself and not in fork(). The example probably assumes fork()
doesn't fail, so it returns a value of 0 for child or more for parent. A
side from not being implemented on Windows, fork() might still fail on
other platforms at least in theory, it sets &error in that case beside
failing. Not being able to fork on Windows is similar in that sense, except
&error probably should be set to an error number that corresponds to
something like "fork() is not supported at this platform". Here is a more
self explanatory fork example:

   fret:=&null
    if (fret := fork()) = 0 then
      write("child")
   else if \fret then {
      delay(1000)
      write("parent")
      }
   else
      write("you are still in parent but couldn't fork, error:", &error)

Documentation is absolutely essential and it is something we have to work
more on. With a team of two and so many other responsibilities and duties
we are struggling to keep up with bug fixes and movements in addition to
documentation. Comments and feedback like yours keeps us motivated  :) .
We have applied many fixes and improvements that is already in svn but
haven't made it to a binary release for windows including support for
blanks in paths and improved portability of iconx and .u files.

Cheers,
Jafar


On Sat, Oct 29, 2011 at 12:17 PM, David Gamey <[email protected]>wrote:

> Jafar & Clint,
>
> I didn't realize fork wasn't implemented in Windows.  Failure wasn't what
> I expected.
>
> And while a solution is the most desirable, documentation is also valuable.
>
> I wonder how many other things fail when unimplemented and provide
> possibly unexpected results.  For instance in the IPL there's an example of
> fork code like so:
>
>    if fork() = 0 then
>       write("child")
>    else {
>       delay(1000)
>       write("parent")
>
> It fails into the parent code which could assume something happened.  A
> runerr would have been harder to ignore.  How it fits into the general
> strategy of such things is probably more important.
>
> Thanks.
>
> David
>
> ------------------------------
> *From:* Jafar Al-Gharaibeh <[email protected]>
> *To:* Clinton Jeffery <[email protected]>
> *Cc:* David Gamey <[email protected]>
> *Sent:* Saturday, October 29, 2011 2:42:55 PM
> *Subject:* Re: fork under windows?
>
> You are correct, Windows doesn't provide any function with the semantic of
> fork(). Probably relaying on spawn family on windows is the closet we can
> get to simulate a similar behavior of fork. I know we already use _spawnvp
> to launch external DOS commands.  I will look for ideas out there and see
> if we can get an "acceptable" behavior.
>
> Jafar
>
>
>
> On Sat, Oct 29, 2011 at 11:16 AM, Clinton Jeffery <[email protected]
> > wrote:
>
> As far as I know, Windows does not provide an equivalent of fork() or
> primitives that would allow us to emulate it. Those windows environments
> that have a fork() are providing an entire OS emulation layer.  But, please
> look into whether the situation has improved any with recent Windows
> versions and 64-bit versions of the OS.
>
> Clint
>
>
> On Sat, Oct 29, 2011 at 11:06 AM, Jafar Al-Gharaibeh 
> <[email protected]>wrote:
>
> David,
>
>     Strangely enough, failing is the correct behavior!  fork is not
> implemented under Windows. Below is a portion of the source code for
> fork(). Not sure why it wasn't implemented in the first place. I will look
> into that and see how hard/portable to include it in the next release.
>
> Jafar
>
>
> #if NT
>       fail;
> #else                    /* NT */
>       if ((pid = fork()) < 0) {
>      IntVal(amperErrno) = errno;
>      fail;
>      }
>       return C_integer pid;
> #endif                    /* NT */
>
>
>
>
>
> On Sat, Oct 29, 2011 at 9:31 AM, David Gamey <[email protected]>wrote:
>
> Jafar,
>
> Not sure where this is at.  Fork fails under Windows 7/x64 running Unicon
> Version 12.0.  July 13, 2011.
>
>    if pid := fork() then
>       if pid ~= 0 then {
>          delay(1000)
>          write("This is the parent process - pid=",image(pid))
>          }
>       else
>          write("This is the child process - pid=",image(pid))
>    else write("Fork failed!")
>
> David
>
>
>
>
> --
> "Let there be no compulsion in religion: Truth stands out clear from
> error" [The Holy Qur'an 2:256]
>
> "Injustice anywhere is a threat to justice everywhere"    Dr. King
>
>
>
>
>
> --
> "Let there be no compulsion in religion: Truth stands out clear from
> error" [The Holy Qur'an 2:256]
>
> "Injustice anywhere is a threat to justice everywhere"    Dr. King
>
>
>
>
> ------------------------------------------------------------------------------
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World&#153; now supports Android&#153; Apps
> for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
>
> _______________________________________________
> Unicon-group mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
>


-- 
"Let there be no compulsion in religion: Truth stands out clear from error"
[The Holy Qur'an 2:256]

"Injustice anywhere is a threat to justice everywhere"    Dr. King
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World&#153; now supports Android&#153; Apps 
for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group

Reply via email to