|
Monday, March 23, 2026 (#82)
|
|
- 08:55 My brain is a bit fuzzy so I'm not sure yet, but it looks like the problem is that the "fetch schema list" process gets stuck when it's run in "keep the process open" mode.
- 09:16 Oh, right! We're using "process is done" as a way of determining whether to stay in the loop -- and of course the process isn't done if we're invoking it in a way that doesn't close it when it's done executing. So the next question is how to tell when the results of a command have finished coming in. Can we assume that a zero-length result means "done"? Or is there some cue/prompt we need to look for?
- 09:24 Apparently it's not receiving anything. Need to make sure the 'list schemas' command is being sent, and in the correct format (i.e. not wrapped in anything except an ending ";" and CRLF).
- 11:12 Aha, this may be the trick: if the process is already running, we don't want to call
DoCommand() -- we want to send it to the process's output stream. (...which may be a trick with ssh2 -- maybe I need to use ssh2_shell() to open it, instead of ssh2_exec().)
- 11:38 The fact that SSH2 might (well... I'm going to assume it does, because I don't see how else it could work) require a different opening-method, where we want to keep the connection open, kinda means I need to reinstate the
DoWait() flag, or something like it. The meaning has shifted slightly since then, though, so maybe a name like KeepOpen() would be better. ...and when it's FALSE, do we want to automatically run DoInOutLoop() the way DoWait() used to (although the code in DoInOutLoop() was then inside DoCommand())? My immediate feeling is "yes, but is there some reason this might make things worse again?".
- I ended up re-reversing the polarity of the neutron flux on this one, and calling it
IsOneShot(). (It does wait before closing and exiting.)
- 15:33 Aha #2: part of the problem is that the way
DoCommand() works, in keep-open situations it just runs the backend process and then exits -- never sending the requested command. The obvious solution, if I've implemented an IsOneShot() flag, is that we not only don't close the process if we're not one-shotting, we also don't open it. (This also fixes that distressing asymmetry, yay!)
- 17:17 I need to map this out to see if the current code-structure is a good model for what we want.
Two scenarios for getting a schema list, where "NextSrv" means the next-link server-object and "ProcSrv" is the end-process-object:
| as a one-shot |
as part of a sequence
|
// inside NewSchemaList()
$oCmd = CommandClass::FromString(SQL)
$oCmd->IsOneShot(TRUE)
NextSrv->DoCommand($oCmd)
|
// elsewhere
$oCmd = CommandClass::FromVoid()
$oCmd->IsOneShot(FALSE) // leave the process running
NextSrv->DoCommand($oCmd) // runs the Engine's process-command in leave-open mode
// inside NewSchemaList()
ProcSrv = $oCmd->QOProcess()->GetIt()
$oCmd->QString()->SetIt(SQL)
ProcSrv->DoCommand($oCmd)
// elsewhere
ProcSrv->Shut() // or should it be NextSrv->Shut()?
|
The above is just a rough-draft; it's probably not quite accurate.