From: mental@...
Date: 2006-03-09T07:56:18+09:00
Subject: Re: idioms for separating out OS-specific stuff

Quoting Joe Van Dyk <joevandyk@gmail.com>:

> I have a few functions that:
>   - get the current user's login name
>   - checks to see what the CPU % of a process is (non the Ruby
> process, another process).  This includes all the threads that
> the
> process has
>   - forks a new process
>   - sees if a process is still running
>   - gets the utilization percentage of a NIC on the machine
>   - the load average of the machine
>   - the number of CPUs on a given machine

...

> And then probe (somwhow?) to figure out what OS I'm running on
> and
> then including the correct modules into my code.  So, if I were
> using
> Linux 2.6, I'd include SystemSpecificFunctions::Linux and
> SystemSpecificFunctions::Linux::2.6.

Maybe it would be better to break up the modules by feature rather
than platform.  Forking processes is the same on BSD and all Linux
flavors, for example.

So, you'd have a module for POSIX-style fork, for example, and
another for /proc/cpuinfo.  The former would provide just the
process creation methods, and the latter would provide just the
methods for enumerating CPUs.

Then you could give each module a singleton method to test for the
presence of its associated feature -- e.g. check whether
'/proc/cpuinfo' exists.

Then you could iterate through those modules and simply include the
ones whose feature checks pass.  Probably you'd want to write some
additional stuff to wrap that process too.

Anyway, advantages:

 - automatically deal with unknown systems that have combinations of
known features

 - avoid duplication between different platforms with common
features

-mental