1 /************************************************************************/
3 /* PROBLEMS WITH THE GDB CODE
5 /************************************************************************/
7 * Go through all of wesommers changes in /u1/sms/gdb
11 - some fatal error stuff
13 * check error return handling on all system calls used by GDB
15 * terminate_db was never written
17 * comments on start_performing_db_operation lie
19 * clean up comments in dbserv.qc
21 * clean up comments in gdb_db.c
23 * Fix ptr <--> int casts on semantic routines
25 * Buffer input through gdb_move_data
27 * Ingres version 5 support
29 * Bouncing connections so that there is only one GDB port
31 * decode of descriptor currently assumes that NULL will be passed if receiving
32 into unallocated descriptor. Autos sometimes aren't null.
34 * Straighten out description of db_query in the library reference.
36 * Document retrieval limit setting
38 * Debug retrieval limit setting
40 * Document -l option on dbserv
42 * Document user and host fields and how to zap for anonymous use.
43 Also, indicate risks of trusting the information in those fields.
45 * There is some inconsistency in the use of tuple vs. tuple descriptor
46 as argument to the routines like FIELD_OFFSET_IN_TUPLE
48 * Offsets would be more convenient if from the start of the tuple rather than
49 from the start of the 0th field.
51 * Some of the routines defined as macros may not work if semicolons are
52 used after invocation. This should be documented our changed.
54 * there is some inconsistency in the semantic routines over which
55 decode routines presume null values of their targets, and which
56 ones actively free any existing data. Likewise for the null
57 routines. For the moment, we'll ignore it as an internal issue,
58 but this should be fixed when it starts causing more trouble than
62 * should check all uses of register declaration to make sure they
65 * make sure null values are handlined properly when tuples are
66 initialized. Looks like the string routines may be easily confused
67 about non-initialized null values.
69 * must update documentation and sample programs to indicate requirement
70 to call the gdb_init routine. Perhaps there should be a closeup routine
73 ** create-tuple-descriptor may be mis-computing data-len in the case
74 where alignment is leaving gas. Looks like the gas is not getting
75 added in. (I think this was fixed during debugging with Saber.)
77 * must make a plan to exhaustively test code paths. Several whole
78 routines have not been tried at all
80 * the design for out of band signalling and operation interruption must
81 be considered more carefully.
83 * perhaps gdb.h should be split into a piece which is visible to all
84 users (i.e. lives in /usr/include) and an internal piece used only
85 for compiling the library.
87 * we need some way to mark and distinguish inbound and outbound half
88 sessions. For the moment, they can be implicit in their position in
89 the connection data structure, but that seems a bit tacky. Could
90 use routine pointers to to do the reading and the writing.
92 * could implement a buffer/flush scheme at some level to avoid repeated
93 and unnecessary system calls for write/read. Not clear what level is
94 best to do this--I'm inclined to do it in the oeprations themselves, not
95 in the transport service.
97 * should come up with a way to encode those types which need a recursive
98 call on cleanup. We can probably get rid of null_tuple_strings that
99 way, and pick up a bit of generality.
101 * don't yet have a proper architecture for the routines used at the
102 server end. Which one's should be exposed and documented to
103 implementors of new services? How general should they be?
105 * CONN_STATUS values should be cleaned up.
107 * make sure the cancellation function in OPERATION_DATA is handled properly.
109 * How do we really want to handle predecessor failing conditions. Should
110 we purge the queue, as currently claimed, or just attempt the next one?
111 Probably just attempt the next one.
113 * select timer handling is being implemented very approximately for now
114 We are setting the full timer each time the real select is called, not
115 accounting for time already elapsed when select is called repeatedly.
117 * level of indirection on select is really not clear
119 * in dealing with file descriptor masks passed to functions, one should
120 probably use the & notation consistently to avoid unnecessary structure
121 copying. See especially in the interfaces to gdb_fd_copy, etc. in
124 * current semantics of op_select imply that lots of manipulation of
125 operation queues will be required as operations complete and the
126 lists get logically shorter. We may want to change the semantics
127 of op_select and/or provide new operations for adding and deleting
128 operations from an operation list, possibly with attendant re-allocation.
130 * how do we do exception handling on the connections?
132 * gdb_hcon_progress: how to handle cancelling, etc.
134 * the distinction between initialization and continuation routines
135 is looking pretty artificial. Leading to duplicate code in
136 places like gdb_hcon_progress.
138 * out of band signalling not implemented. The sockets are set to null
141 * when starting peer sessions a race condition is built into the current
142 algorithm. startup may fail when the two sides are initiated at about
143 the same time. Must be fixed for production use.
145 * start_peer_connection has no way to return a reason for failure.
147 * connections are currently made to a well known port. Eventually this
150 * one could argue that the creation of the listening socket should be done
151 once during initialization, not repeatedly. On the other hand, this
152 significantly raises the cost for someone who never listens.
154 * We could automate the activation of gdb_init by checking for a flag
155 in the appropriate routines.
157 * define consistent set of op_results, apply them in gdb_ops.c
159 * synchronous calling of continuation routines may be a mistake? I don't
160 think so, since the length of the chain is statically limited. Would
161 be a mistake in the case of extensive re-queueing, but then we go back
162 to the queue manager, NO?
164 * queue_operation takes a half connection as an argument, but they are
165 not properly described in the spec. There should be macros to
166 extract the input and output half connections from a connection.
168 * our writeup should note ease of supporting shared state servers
169 (e.g. a very live conferencing system?)
171 * for performance, changes should be made to minimize the number of read
172 and write system calls done. This could (perhaps) be done with look-behind
173 on the outbound and buffered read on the inbound queues, used in conjunction
174 with the iovec technique. Should improve performance significantly.
175 May also need a 'block' hint for use on a half connection which allows
176 an application queueing lots of little requests to get them batched
179 * we're not handling the case where select returns -1 in cnsel, particularly
180 for EBADF indicating a closed descriptor.
182 * start_peer_connection should use randomized waits to re-try connect and
183 avoid the current startup window.
185 * need a better way to return errors on things like starting a connection.
186 should scan all of the synchronous interfaces to find out where this
189 * it's possible that HCON_BUSY should be replaced by a mechanism to lock
192 * most operations should have cancellation routines.
194 * when tuples are sent for server/client stuff, make sure the descriptors
195 are properly destroyed when not needed
197 * should integrate deletion as an operation on a type, along with
198 optimization for nop'ing it. Should then go through all of code
199 which does things like null-tuple-strings and straighten it out.
201 * document start_sending_object start_receiving_object
203 * anything which starts an operation should make sure that the
204 status of the supplied operation is NOT_RUNNING. There is a
205 nasty condition which results when the same operation is started
208 * disable GDB_PORT because it encourages conflict among applications
210 * implement validate routines in create_forking_server
212 * check userinfod and inetd to make sure that server environment is
215 * build async versions of db ops, at both client and server
217 * use of "string" vs "STRING" in documentation is confusing
219 * macros for getting at fields in tuples
221 * document non-portabilities
223 - representation of data by enc/dec
225 * are text lengths being handled well on queries? (Looks ok, 9/17/86)
227 * lots of error checking is missing in dbserv
229 * Confusion in documentation as to whether receive_object allocates
230 a new relation (for example)
232 * delete relation needs a way to delete non-contiguous data other
235 * syntax checking of queries
237 * return codes for operations, especially DB operations, are a mess.
239 * we should have some equivalent of perror
241 * we can possibly give some information about where we were at
242 the time of a failure if we keep a logical stack.
244 * gdb_init should be callable multiple times
246 * i.d. fields are currently implemented with strings, which is very
247 slow. Should re-implement with integers as magic numbers
249 * must figure out handling of errors on queued database requests.
250 which ones cause a tear-down. Are there problems dequeueing
251 the appropriate operations in the right order? Could things get
252 out of sync if other things are queued ahead? Seems to require
253 a pretty good understanding of how things get cancelled implicitly
254 and explicitly. Maybe all explicit cancellations should be done
255 using terminate_db. There is also some question about how
256 careful we have to be in handling the explicit cancellation of
257 a single db operation, or whether that should be supported. Not
258 clear that we have enough of a bracket context to do that cleanly.
260 * document preempt_and_start_receiving_object, also, maybe should
263 * Notes should be provided on create/delete semantics. Current is:
264 tuple_descs are reference counted. Your creates should
265 match your deletes. Same is true for relations and operations.
266 Likewise tuples EXCEPT: if you create a tuple, add it to
267 a relation, and delete the relation, the tuple itself is
268 deleted, and all dangling pointers to it are invalid.
270 * Must assign version numbers to all programs, documents and files
272 * gdb_ugd should reference K&R
274 * should make a CSTRING_T to represent a null terminated string by its pointer
276 * should be able to limit the number of tuples retrieved.
278 * Perhaps should be able to interrupt ongoing database operations, or
279 in any case, the restriction on severing the connection should be
282 * send_object and receive_object should return OP_SUCCESS not OP_COMPLETE
284 * create_type is documented, but it does not exist. Also, it is mentioned
285 in the language reference, but not really written up properly.
287 * add missing chapters to the user's guide
289 * Steve: forward reference in user guide to async
291 * Steve: diagrams of general system structure and flow
293 * More reference material in user guide
297 * what are rules about memory allocation
300 * confusion over pointers and macros in documentation
304 * i.d. fields should be changed upon deletion to try and catch misuse
307 * explicit host addresses are not accepted
309 *debugging forked servers is very difficult
311 *there should be more detailed failure codes on send_object receive_object
313 \f/************************************************************************/
317 /************************************************************************/
319 * need a routine to wait for all the operations in a list
320 should be easy to build out of op_sel (DONE)
322 * there should be a macro called TERMINATED for internal use which
323 would be true when an operation was completed or cancelled. This
324 should be used by most of the routines which check for completion,
325 in anticipation of the day when error recovery is done properly.
326 (DONE...name of the macro is OP_DONE)
328 * see if select can be used with a listening socket (DONE...it works)
330 * we need a send_object and receive_object as well as start_sending_object
331 and start_receiving_object (DONE, but documentation is missing)
333 * should put handling in select for the exceptfd case to catch closing
334 connections, and likewise should check for errors on read/write. Maybe
335 only errors on read/write should be checked. (DONE..exceptfd's are
336 irrelavent...I think they're for getting signals, anyway, we do the
337 right thing now when a socket fails by closing the corresponding
340 * make sure port numbers are handled OK in the server/client model
343 * the database server MUST delete its relations, and we must decide
344 how tuple descriptor reclamation is to be done (Done)
346 * make db_alloc and db_free replaceable (Done)
348 * James had problems with create_tuple_descriptor in that he got
349 one of the parameters duplicated (not a gdb problem)
351 * async queries and db_ops (Done)
353 * we should put eye catchers into structured data and check it. (done)
355 * db_query is not nearly asynchronous enough (Done)
357 * Strings: James forgot to initialize strings after creating tuple;
359 * we are missing a delete_relation routine, which would have to
360 recursively delete all tuples after calling delete_tuple_strings
361 or whatever on them. This should be called by the decode relation
362 and the null relation semantic routines. (Done)
364 * naming inconsistency between "new-tuple" and "create-_____" all others (Done)
367 /************************************************************************/
369 /* Problems in Providing SQL Support
371 /************************************************************************/
373 * Character strings in SQL limited to 255 bytes, in literal at least