[M3devel] variations of waitpid..?

[Mika Nystrom]

I don't think it should be possible to stop other threads if the
runtime could even conceivably support an environment where that's
not necessary.  You're introducing dependencies that will lead to
(undetectable) deadlocks.  People who declare their own <*EXTERNAL*>
things are, as usual, on their own.

     Mika

Jay writes:
>
>Hm. How about:
> 
>PROCEDURE Scheduler.DoesWaitProcessYield() : BOOLEAN?
> 
>?
>true for pthreads/win32/cygwin
>false for userthreads
> 
>duplicated privately in sysutils to avoid depending on newer m3core
> like I did for the portable C-wrapped waitpid
> 
>?
> 
>That way..the other code can do whatever it already is doing,
>no need to come up with abstractions for looping with nohang,
>vs. that plus the status loophole.
> 
>The older fix I put it can be shrunk.
> 
>The name of this is debatable, but I think the minimal level of abstraction is
> goodness.
> 
>The name is actually perhaps too..complicated..like, what does it mean?
>Who uses it? What do they do with it?
> 
>It means that waiting on a process to end allows threads in the waiting proces
>s to run.
>Perhaps it is too low level.
> 
> 
> - Jay
>
>
>
>----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Wed, 31 Dec 2008 05:33:22 +0000
>> Subject: [M3devel] variations of waitpid..?
>>
>>
>> variations of waitpid..
>>
>> Hey, we already have, that I put in on my initiative, months ago:
>>
>> C:\dev2\cm3.2\m3-libs\m3core\src\thread\POSIX\ThreadPosix.m3
>>
>> PROCEDURE WaitProcess (pid: int): int =
>> (* ThreadPThread.m3 and ThreadPosix.m3 are the same here except ThreadPosix.
>m3 calls Pause(). *)
>> VAR
>> result: int;
>> statusM3: Uwaitpid.waitpid_status_t;
>> CONST Delay = 0.1D0;
>> BEGIN
>> LOOP
>> result := Uwaitpid.waitpid(pid, statusM3, Uwaitpid.WNOHANG);
>> IF result # 0 THEN EXIT END;
>> Pause(Delay);
>> END;
>> 0 *>
>> RETURN statusM3.w_Loophole;
>> END WaitProcess;
>>
>> pthreads and cygwin:
>>
>> C:\dev2\cm3.2\m3-libs\m3core\src\thread\WIN32\WaitProcessCygwin.m3
>> and
>> C:\dev2\cm3.2\m3-libs\m3core\src\thread\PTHREAD\ThreadPThread.m3
>>
>> PROCEDURE WaitProcess (pid: int): int =
>> (* ThreadPThread.m3 and ThreadPosix.m3 are very similar. *)
>> VAR
>> statusM3: Uwaitpid.waitpid_status_t;
>> BEGIN
>> LOOP
>> WITH r = Uwaitpid.waitpid(pid, statusM3) DO
>> IF r> 0 THEN
>> RETURN statusM3.w_Loophole;
>> END;
>> < 0*>
>> END;
>>
>> END;
>> END WaitProcess;
>>
>> win32:
>> PROCEDURE WaitProcess (pid: int): int =
>> BEGIN
>>
>> RETURN 0;
>> END WaitProcess;
>>
>> ThreadPThread and WaitProcessCygwin should share code, but that's not the po
>int.
>>
>> However, now, to fix sysutils, we need something LIKE:
>>
>> UNSAFE INTERFACE SystemPosixWaitPid;
>> FROM Ctypes IMPORT int;
>> FROM Sysutils_Uwaitpid IMPORT waitpid_status_t;
>> FROM Utypes IMPORT pid_t;
>>
>> PROCEDURE WaitPid(pid: pid_t; VAR status: waitpid_status_t): int;
>>
>> BEGIN
>> END SystemPosixWaitPid.
>>
>> pthreads:
>>
>> UNSAFE MODULE SystemPosixWaitPidEfficient EXPORTS SystemPosixWaitPid;
>>
>> FROM Ctypes IMPORT int;
>> FROM Sysutils_Uwaitpid IMPORT waitpid_status_t, waitpid;
>> FROM Utypes IMPORT pid_t;
>>
>> PROCEDURE WaitPid(pid: pid_t; VAR status: waitpid_status_t): int =
>> BEGIN
>> RETURN waitpid(pid, status, 0);
>> END WaitPid;
>>
>> BEGIN
>> END SystemPosixWaitPidEfficient.
>>
>> user threads:
>>
>> UNSAFE MODULE SystemPosixWaitPidPause EXPORTS SystemPosixWaitPid;
>>
>> FROM Ctypes IMPORT int;
>> FROM Sysutils_Uwaitpid IMPORT waitpid_status_t, waitpid;
>> FROM Utypes IMPORT pid_t;
>>
>> PROCEDURE WaitPid(pid: pid_t; VAR status: waitpid_status_t): int =
>> VAR result: int;
>> CONST Delay = 0.1D0;
>> BEGIN
>> LOOP
>> result := waitpid(pid, status, Sysutils_Uwaitpid.WNOHANG);
>> IF result # 0 THEN
>> EXIT
>> END;
>> Thread.Pause(Delay)
>> END;
>> END WaitPid;
>>
>> BEGIN
>> END SystemPosixWaitPidPause.
>>
>> questions:
>>
>> Aside: Where do I put "unsafe"?
>>
>> Relevant: Sysutils has to implement this itself, right?
>> Due to bootstrapping concerns.
>>
>> But we should still put /something/ in m3core, right?
>>
>> So then the big question, what to call it?
>>
>> Probably, the existing WaitProcess that does more than this WaitPid, should 
>be scaled
>> back and only do what WaitPid does?
>>
>> I will likely commit exactly what is shown above.
>> The new interface and modules are in sysutils. The interface is private.
>>
>> The unfinished part is putting something in m3core, that sysutils could use,
> if
>> not for boostrapping issuers, that it could use in the future.
>>
>> I kind of thing something a bit more is needed.
>> You know, the Win32 implementation that asserts(false) is suspicious.
>> At the very least, it should be removed.
>>
>> I suspect I am missing something though, as suggested by Win32 having an ass
>ert(false) implementation.
>> Either that needs to be removed, or somehow the code can be unified, using j
>ust the existing m3core/libm3
>> interfaces?
>>
>> I also suspect part of the problem is that sysutils implements to a large ex
>tent
>> the same abstractions as m3core and/or libm3, but with variations, causing i
>t to be unable
>> to build on what is there, but having to reinvent..which suggests the m3core
>/libm3 abstractions
>> maybe are not general/featureful enough.
>>
>> (Btw, unstated above, is that sysutils/m3makefile will have the same sort of
> switch as m3core does, wrt if it builds for user/alaram threads or kernel/pth
>reads.)
>>
>>
>> ??
>>
>> - Jay