While Developing an OS Abstraction layer for a multi-modular system, which approach should one take:
What are the pros and cons of these approaches? Also lay down any other if possible?
Back when it was my job to architect, manage and lead (mostly by-doing;-) such layers, I had an easy time deciding: some operating systems (VMS, then-brand-new Win-NT) had very heavy-weight process spawning (so it really needed a lot of provocation to spawn a new process!-), while at the other extreme others (such as BSD 4.3 with its then-brand-new vfork!-) positively encouraged you to spawn as many processes as you wished and had very little overhead in doing so. Therefore, I judged that leaving to the application programmers the decision of whether to spawn or not was irresponsible - we (the "Base Libraries" group) really had to provide an abstraction layer that would spawn or not depending on the underlying operating system. It worked pretty well... but also it was 15/20 years ago, on a certain class of machines (workstations) with a wide variety of OS's but reasonably uniform endowments in memory, cores (one: no multi-cores back then!-) and the like.
Were I to take the same job today, I'd first push the stakeholders (top mgmt, product marketing, or whoever) for a clear definition of the range of platforms we have to support -- what OS's, what range(s) of HW endowments. If -- as I suspect -- that's as wide in its way as it was back then, my architecture would be similar in terms of hiding the concept of process spawning from application programmers. But maybe the target range is different, e.g. "smartphones and cheap netbooks", which would make the choice iffier... though abstracting process creation away from app programmers is the SAFE choice, and you should expose this layer only if you're willing to take a risk on said app programmers' general skills AND whatever uniformity you can count on now in your range of platforms, remaining reasonably stable in the future!-)