Basic Question on Engine Programming

It's really a fairly minor distinction... only a few lines of code different. I'd go for the second approach, since it means your engine is better able to handle timing.

I think either method is good, especially if your new to engine programming.
One point to make about option 2 is that you would need to provide some kind of callback mechanism so the user can hook in their own code into the main loop.

Also what you decide about OS portability might affect your decision (integrating the main loop into the engine may, or may not, require your engine to have knowledge of the operating system, depending on just how you implement both the loop and the OS abstraction.)

Edit: Theres no reason why you couldn't do both, by default leave the loop open the user but also provide utility functions/classes to hide the loop if so desired.

I would go with the second approach. Just have a task manager where the user can add tasks and set the tasks' properties (which thread should they belong to, what is the maximum number of times per second they can get updated, what is their priority etc.).

As was said, they're really only a few lines different. I always take the first approach with the reason being that it makes working with the engine while also running other possibly unrelated code in the same thread very easily.

With the second approach, as soon as the engine is running, any code that is to be run in the same thread has to be done through the game engine, even if it doesn't directly pertain to the game, which can be very intrusive to an application's design. Libraries and engines which force you into a particular design are not only an annoyance, but they can often be reason enough to avoid using the library entirely.

If you don't really care about that, both approaches are just as good. Still, with the first approach you can very easily just encapsulate it to have it work like the second approach. On the other hand, it is not possible to encapsulate the second approach to make it act like the first, so I'd recommend starting with the first approach even if in the end you want to have it work like approach number two (remember, it's only a few lines extra to turn #1 into #2).

Another thing to think about that probably won't come up in your project is that concept #1 is easily nestable in a single thread whereas concept #2 is not. By that I mean, imagine a simulation which inside itself runs another simulation. If the inner simulation took approach #2, you wouldn't be able to easily accomplish this type of encapsulation without possibly setting up some complex callbacks in the inner simulation which update the outer simulation. This problem stems from the fact that once an engine taking approach #2 is started, it takes control of the thread until it completes the entire simulation. However, if you were to take approach #1, an inner simulation is simple to create and work with and does not affect the design of the rest of your application -- all you have to do is call the inner simulation's update function sometime during the updating of the outer simulation.

Again, while that particular situation probably will not come up in your current project, it is a good idea to think about as that style of logic can apply to any type of library or engine which involves repeated udating of states. A good rule to follow is to always start off with an approach like #1 where possible and just provide a class or function which encapsulates it and turns it to #2 for situations where working with it in that manner seems easier. Both styles are just as easy to create, so you might as well program the one which can be easily adapted to act like the other.