Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>In the case of not CRITICALERROR | CRASH, where the app would be expected to continue after the logging call, it would be better to queue, (thread-safe producer-consumer queue), off each log struct to a logging thread that performs the requested action/s. The logging thread would normally free the structs after handling them. Some advantages:</p> <p>1) The action taken for each logging request is reduced to mallocing the struct, loading it and pushing it onto the queue. If the disk is temporarily busy, or has high latency because it's on a network, or becomes actually unavailable, the calling thread/s will continue to run almost normally. With this, the set of apps that will fail just because the logging has been turned on is reduced. A user with some intermittent problem that you cannot reproduce can be instructed to turn on the logger with little chance that the logging will affect normal operations or, worse, introduce delays that cover up the bug.</p> <p>2) For the same reasons as (1), adding/changing logger functionality, even at runtime, is much easier. For example, maybee you want to restrict the size of log files or raise a new date/timestamped log file every day. A 'normal' call would introduce a long delay into the calling thread while the old file was closed and the new one opened. If the logging is queued off, all you get is a temporary increase in the number of queued log structs.</p> <p>3) Controlling the logging is easier. In a GUI app, the logger could have its own form where the logging options can be modified. You could have a 'New log file now' button which, when clicked, queued a 'LOGCONTROL' struct to the logging thread, along with all the other logging messages. When the thread gets it, it opens a new log file.</p> <p>4) Forwarding the log messages is fairly easy. Maybe you want to watch the logged messages, as well as write them to disk - queue up a 'LOGCONTROL' struct that instructs the thread to save a function ptr passed in the struct and henceforth call this function with subsequent logging messages after writing them to disk. The function passed could queue up the messages to your GUI for display in a 'terminal' type window, (PostMessage on Windows, Qt etc. have a similar functionalities to allow data to be passed to the GUI). Sure, on ***x, you could open a console window and 'tail-f' the log file, but this will not appear particularly elegant to a GUI user, is more difficult to manage for users and is anyway not available as standard on Windows, (how many users know how to copy paste from a console window and email you the error message?).</p> <p>Another possibility is that the logging thread might be instructed to stream the log text to a remote server - another 'LOGCONTROL' struct could pass the hostname/port to the logger thread. The temporary delays of opening the network connection to the server would not matter because of the queued communications.</p> <p>5) 'Lazy writing' and other such performance enhancements become easier, but:</p> <p>Disadvantages:</p> <p>1) The main one is that when the log call returns to the requestor, the log operation has probably not yet happened. This is very bad news in the case of CRITICALERROR | CRASH, and can be unacceptable in some cases even with 'ordinary' logging of progress messages etc. There should be an option to bypass in these cases and a direct disk write/flush made - fOpen/CreateFile a separate 'Direct.log', append, write, flush, close. Slow - but secure, just in case the app explodes after the log call returns.</p> <p>2) More complex, so more development, more conditionals, bigger API interface include.</p> <p>Rgds, Martin</p>
    singulars
    1. This table or related slice is empty.
    1. PODesign considerations for an error logging/notification library in C
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USMartin James
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODesign considerations for an error logging/notification library in C
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COMartin, thanks for the excellent insight you've provided. Logging is a costly ex ante investment up front, but I think proper care and attention will net valuable rewards. I've also heard others talk about using a separate process purely for logging, but then that raises even more portability concerns, since interprocess communication tends to present challenges to portability.
      singulars
      1. PO
      1. USkmore
    2. COYup - IPC is slower and introduces the problem of copying/marshalling the struct. A classic non-clever P-C queue needs two things from the OS: a semaphore for the logger thread to wait on and thread-safe count the queue entries, a lock to protect the queue - things available on all multiTasking OS. I can see how a process, with its protected address space, might be useful in some circumstances, but the performance hits are too much for me even without the portability issues.
      singulars
      1. PO
      1. USMartin James
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload