Re: [boost] [GSoC] Scheduled Executors beta 1 release

Subject: Re: [boost] [GSoC] Scheduled Executors beta 1 release
From: Ian Forbes (ian.forbes_at_[hidden])
Date: 2014-07-26 13:34:28

> Your queue is flawed: what if T's copy constructor is invoked when calling pull(), and it throws an exception? Also, pull() is conventionally called "pop".

I can't see anyway around this as the queue needs to be locked to guarantee serial execution to top() and pop().
The convention of having top() and pop() to avoid this can't be used since a call to top() followed by a call to pop() on the same thread are no guaranteed to happen consecutively.

One solution would be have T top(mutex* p) that would accept a mutex pointer and store the internal queue's mutex address into this. The method would lock the queue but would not unlock it. 
Then we could have void pop(mutex* p) that would take that mutex pointer and unlock it after the pop.
Users could either unlock mutex after top or pass it to pop to unlock for them.
This however is a fairly poor solution since an uncaught copy ctor would cause the queue to be locked forever. 

mutex* m;
T copy = queue.top(m);
//Queue is now locked. If T's copy ctor throws we have to unlock the mutex, otherwise deadlock.
queue.pop(m);
//A call to pop will unlock the mutex through m. 

If you have another solution please provide it. Also see Vicente's comments on this as well. 

Ian,