No recovery mechanism from Thread instantiation faillure

[pan-]

Instantiating an object of type Thread will start the thread immediately.

If the thread can't be started then the system will enter in error state.

It should be possible to use the c++ Thread wrapper and recover from errors if the thread can't be started.

One solution could be to not start the thread at instantiation point but instead let the user start it explicitly by calling the function Thread::start.

Another solution would be to embed a status in the Thread object which allow to verify if the thread is started or not after its instantiation.

class Thread { 

    bool is_running();

    operator bool() { 
        return is_running();
    }
};

This change preserve backward compatibility and let the user write simple code like this:

Thread my_thread(do_something);
if (!my_thread) { 
   // thread not started
   // recovery here
}

[0xc0170]

Thread object defines a method:

    /** State of this Thread
      @return  the State of this Thread
    */
    State get_state();

If an error occurs during ctor, I would expect to get a state, and check for Inactive - not created or terminated?

States:

    /** State of the Thread */
    enum State {
        Inactive,           /**< Not created or terminated */
        Ready,              /**< Ready to run */
        Running,            /**< Running */
        WaitingDelay,       /**< Waiting for a delay to occur */
        WaitingInterval,    /**< Waiting for an interval to occur */
        WaitingOr,          /**< Waiting for one event in a set to occur */
        WaitingAnd,         /**< Waiting for multiple events in a set to occur */
        WaitingSemaphore,   /**< Waiting for a semaphore event to occur */
        WaitingMailbox,     /**< Waiting for a mailbox event to occur */
        WaitingMutex,       /**< Waiting for a mutex event to occur */
    };

[pan-]

@0xc0170 Thanks Martin, in that case then the instantiation should not enter the error state in case of error but instead set a state: https://github.com/mbedmicro/mbed/blob/master/rtos/rtos/Thread.cpp#L51-L61 .

[0xc0170]

cc @geky What do you think about this proposal, to remove "fatal" error() and let user to handle some use cases

[geky]

There was a lengthy discussion about this over here (unfortunately private): #79

I agree implicitly starting the thread in the contructor is a relatively terrible idea due to the lack of error reporting (but hindsight is 20x20). Providing the error state is a good workaround, but auto-starting in the constructor has other downsides such as encouraging pre-main thread spawing, which can put your application in really weird states.

We decided the way forward was @pan-'s first suggestion. Provide a non-starting constructor (here) and a Thread::start function (here). This lets you catch errors in Thread::start's return value.

Unfortunately as @pan- points out, we can't simply remove the auto-starting constructor. The plan was to mark the constructor as deprecated once we had a mechanism to do so. Now we have MBED_DEPRECATED, so there's no reason we can't.

cc @niklas-arm: feel free to correct me if I missed anything

[pan-]

Explicit deprecation of those constructors is a really good thing.

Only one way to start a thread is another good thing.

I think I can close this now.