[MEP] Prohibit Blocking Calls by Emulator

[Fred Eisele]

Indeed, if the policy were approved then I would
proceed to find and fix the violations of that policy.
The impetus for this MEP is a bug that I had previously reported.
Originally, there was some discussion surrounding that bug, but
ultimately that bug was not fixed.
I was unsure what tack to take next as I didn't know why it languished.
If this policy were adopted that would give me permission to push harder.
Also, I really think this policy is *key* to the value of mozart-oz and 
should be clearly stated somewhere.

On 8/4/05, Christian Schulte <schulte at imit.kth.se> wrote:
> Hi all,
> 
> I am not so sure whether this is really a MEP: I agree that this is quite
> good and noble but what is the immediate impact on Mozart. If the MEP were
> along the lines "in order to follow that policy, I am going to fix all the
> issues violating that policy, namely: a, b, c, ...", I'd be thrilled. So, we
> can file it and so what.
> 
> Christian
> 
> --
> Christian Schulte, http://www.imit.kth.se/~schulte/
> 
> -----Original Message-----
> From: mozart-hackers-bounces at ps.uni-sb.de
> [mailto:mozart-hackers-bounces at ps.uni-sb.de] On Behalf Of Fred Eisele
> Sent: Saturday, July 30, 2005 1:19 AM
> To: Mozart Hackers
> Subject: [MEP] Prohibit Blocking Calls by Emulator
> 
> 
> MEP: #
> Title: Prohibit/Prevent Blocking Calls by Emulator Process
> Version: $Revision: 0.0 $
> Last-Modified: $Date: 2005/07/29$
> Author: Fred Eisele <phreed at gmail.org>
> Status: Proposed
> Type: bug-fix, policy-change
> Created: 2005-07-29
> Post-History:
> 
> Proposal:
>  Accept the following policy/rule...
>  While it is perfectly acceptable for a thread to block, no (oz) function
> call will be allowed that causes the emulator process to block.
> 
> Example:
>  A case where this rule was not being followed is illustrated by bug# 1438.
> I am working on a better test case sample where...  Two threads are started,
> a client and a server.  The server thread provides a happy message ('hello')
> to a client thread.  The client thread is started first and allowed to block
> before attempting to start the server.  It is necessary to introduce a small
> delay before starting the server
>   as there is a possibility that the server process may win the race.
> 
> Discussion:
>  Are there other situations where the emulator could block
>  that would need to be  corrected should this policy change be approved?
> This would imply that certain functions be deprecated or replaced
>   e.g. OS.accept by OS.acceptSelect,
>        OS.connectNonblocking and OS.connect (both have issues see bug#1438
>        etc.
> 
> References:
> http://www.mozart-oz.org/pipermail/mozart-hackers/2003/001242.html
> 
> Local Variables:
> mode: indented-text
> indent-tabs-mode: nil
> sentence-end-double-space: t
> fill-column: 70
> End:
> 
> ____________________________________________________________________________
> _____
> mozart-hackers mailing list
> mozart-hackers at ps.uni-sb.de
> http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
> 
>