From: Dave C. <dj...@ob...> - 2005-01-11 18:10:22
|
Skip Montanaro wrote: > Perhaps I spoke a bit too soon... > > Dave> There are two possible ways to attempt a fix. > > Dave> 1) Construct the Fetcher in the FETCHING state. This will mean > Dave> that any exception raised in the ct_command() or the ct_send() > Dave> function will result in ct_cancel(CS_CANCEL_ALL) when the > Dave> Fetcher is deleted. > > Dave> In _FetchLazy.__init__() change: > Dave> self._state = _LAZY_IDLE > Dave> to > Dave> self._state = _LAZY_FETCHING > > Skip> This didn't work. > > Dave> 2) Set the Fetcher state to FETCHING immediately before calling > Dave> ct_send() in _FetchLazy.start(). > > Dave> In _FetchLazy.start() change: > Dave> status = self._cmd.ct_send() > Dave> to > Dave> self._set_state(_LAZY_FETCHING) > Dave> status = self._cmd.ct_send() > > Skip> This did... > > Solution #2 worked on Solaris/Intel, but not on Linux (neither did solution > #1). Cursors created after an error still give a ct_send() error with this > message when their execute() method is called: > > ct_send(): user api layer: external error: This routine cannot be called > because another command structure has results pending. Hmmm... Looks like I have to do some more research into the CT library state machine. - Dave -- http://www.object-craft.com.au |