Proposal: POSIX process group API reform

[Favonia]

Thanks for the feedback. I agree that newtype stuffs can be discussed
in another proposal. Let's focus on the package unix now.

I agree with most of your suggestion except the name
newProcessGroup[For]. I would rather only introduce
createProcessGroupFor and deprecate createProcessGroup for following
reasons:

(1) "create" seems to be more consistent than "new" with the rest of
the API; there is "createSession" and the committed patch in trac
#3994 is using the flag create_group.

(2) People who really want the new functionality of createProcessGroup
can just write createProcessGroupFor =<< getProcessID. This expression
should be future-proof.

In summary here is the full list of proposed changes in the first stage:

getProcessGroupID => same
getProcessGroupIDOf => new
createProcessGroup => deprecated; will be changed in the future
createProcessGroupFor => same as the old createProcessGroup
joinProcessGroup => same
setProcessGroupID => deprecated; will be changed in the future
setProcessGroupIDOf => same as the old setProcessGroupID

The previous patches on the trac actually already preserved
setProcessGroupID and createProcessGroup for backward compatibility.
(Sorry that I did not mention this.) All the patches have been tested
and updated with better documentation.

Regards,
Favonia

On Wed, May 11, 2011 at 5:11 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> On 04/05/2011 14:18, Favonia wrote:
>>
>> I am proposing a POSIX process group API change in order to
>> (1) make ProcessGroupID a newtype of CPid, and
>> (2) make it possible to query the process group of an existing process.
>>
>> The motivation is that currently there is no way to query a process
>> group of an existing process, but it seems needed for a proper
>> implementation for ticket #3994. Also it seems nice if the compiler
>> can do distinguish ProcessGroupID from ProcessID, just like Fd from
>> CInt.
>
> We should not make ProcessGroupID a newtype, because execpt for Fd, none of
> the other types in this family are newtypes.  If we want to make them all
> newtypes, that should be done in one pass with a separate proposal.
>
> I suggest retaining more backwards compatibility:
>
>  - do not change setProcessGroupID yet: the functionality
>    is already provided by joinProcessGroup.  Instead just
>    deprecate it.
>
>  - instead of changing createProcessGroup, add
>
>      newProcessGroup :: IO ProcessGroupID
>      newProcessGroupFor :: ProcessId -> IO ProcessGroupID
>
>    and deprecate createProcessGroup.
>
>  - Sometime later, change setProcessGroupID to the new version
>    and undeprecate it.
>
>> PS: Sorry but the patch to the package base is not fully tested, as I
>> have not figured out the correct way to compile package base (even
>> without the patch). However the patch to the package unix should work
>> independently of the patch to the package base.
>
> If you make patches, I'll test and commit at the end of the discussion
> period.
>
> Cheers,
>        Simon
>