Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I really don't know anything about .NET, but I can share my few experiences with asynchronous programming in the C and Linux world.</p> <p>First of all, take this with gallons and gallons of salt, but: using threads (rather than processes) is often a bad idea. <strong>Processes only share the information you want to share</strong> (through message passing), while <strong>threads share <em>everything</em></strong>. Because you can't share every single object accessible by code with every thread, you have to explicitly indicate what is not shared by using locks and whatnot. Working with processes is often easier because you only have to specify what you <em>do share</em>. I can't remember where I read this, but someone compared multithreaded programming with the style of programming you'd have to follow on a system without memory management (e.g. DOS) or in an operating system kernel. That type of programming is often unnecessary in userspace because the OS and MMU (memory management unit) take care of that for you.</p> <p>One example of a large, asynchronous program that doesn't use threads is PostgreSQL. In fact, on its Todo list, it is listed under "Features We Do <em>Not</em> Want" <a href="http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want" rel="nofollow noreferrer">(see here)</a>. Granted, there may be cases now in the future where threads could speed up tasks (because they're cheaper to instantiate than processes), but they aren't (and won't be any time soon) used as the main vehicle of asynchronous programming in PostgreSQL.</p> <p>An alternative to threads and processes is to simply use one thread and one process, but have an event loop and quick handlers. However, drawbacks to this approach include: * Your code has to be chopped up into pieces that don't sleep. Instead of calling a function that simply downloads a URL and returns a result, you have to supply a callback for when the result is ready and also have your main loop respond to events related to downloading a URL (e.g. a single packet arrived). * You might not be able to avoid sleeping, or it may be unduly difficult.</p> <p>I would recommend the single-process, single-thread approach for a relatively simple daemon. However, if the role of that daemon starts getting large and the code gets complicated, it may be time to split it up into separate processes.</p>
    singulars
    1. This table or related slice is empty.
    1. POIs multithreading the right way to go for my case?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJoey Adams
    1. USJoey Adams
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COErlang comes to mind. Scalable lightweight processes that communicate using message passing semantics.
      singulars
      1. PO
      1. USTim Lloyd
    2. COWhile your answer is 100% correct and I upvoted it, in my case almost any object is shared due to the way clients can modify almost. The few resources that don't need sharing are either immutable or accessed by a single thread.
      singulars
      1. PO
      1. USJulien Lebosquain
    3. CO@Julien Lebosquain Consider a database server and its clients. The clients can arguably modify "just about anything" on the database. However, the client and server are well-separated and talk to each other through a protocol. Of course, it would be a lot of needless work to implement a SQL interface between your clients and server. You could use a simple encoding indicating the intention of the client to the server. Perhaps .NET even lets you pass functions bound to parameters (closures) to/from client and server.
      singulars
      1. PO
      1. USJoey Adams
 

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