Rafal,
That won't work either. The reason is the lock is not acquired until prelock
is called. That is not where we are in the kernel. We are in the loop before
that call. So the state of the default (or CS) driver is:
* no lock thread has been issued (that's done in prelock) so we are in
LOCK_NOT_STARTED state
* get_data is being called but no data can be read and we aren't "ready" for
anything
* this is the point in the kernel where the drivers return "extra" data (I
think) and the default driver has no "extra" things to return
So what should happen here? READY works. OK does not.
Chuck
> -----Original Message-----
> From: Rafal Somla [mailto:rsomla@stripped]
> Sent: Wednesday, November 07, 2007 7:55 AM
> To: Chuck Bell
> Cc: commits@stripped; 'Lars Thalmann'
> Subject: Re: bk commit into 5.2 tree (cbell:1.2610) BUG#31383
>
> Chuck Bell wrote:
>
> > The driver has not locked its tables so it returns an empty
> buffer and
> > the return code of OK (per your insistence). The kernel in
> the method
> > Backup_pump::pump() inspects the return code and then drops
> the buffer
> > because there isn't anything in it. The pump() method returns to the
> > Scheduler::step() method which returns to
> write_table_data() and then
> > the code gets stuck in the loop:
> >
> > @491 in data_backup.cc
> >
> > while (sch.init_count > 0)
> > if (sch.step())
> > goto error;
> >
> > However, if the driver returns an empty buffer and the
> return code of
> > READY when the lock has not been acquired, the code in the method
> > Backup_pump::pump() inspects the return code, identifies
> that we are
> > waiting (state= backup_state::WAITING;) and the drops the buffer
> > because there isn't anything in it. The pump() method
> returns to the
> > Scheduler::step() method which returns to
> write_table_data() and then
> > the code proceeds past the loop on to sch.prepare().
>
> Isn't the problem caused by your get_data() *never* returning
> READY? That is, the change I'm suggesting is not to always
> return OK but return OK only until the tables are locked
> (which can be checked by inspecting lock_state member).
> Once they are, get_data() *should* return READY and then the
> above loop will terminate I think.
>
> Rafal
>
