Recherche avancée

Sur d’autres sites (13728)

• Revision 16012 : ne pas charger local_xx.php plus d’une fois par hit. Utiliser un @ dans le ...

  2 septembre 2010, par cedric@… — Log

  ne pas charger local_xx.php plus d’une fois par hit. Utiliser un @ dans le idx_lang temporaire pour eviter tout risque de collision, possible depuis que les _ sont autorises dans les noms de module de langue

• 2 GB Should Be Enough For Me

  31 août 2010, par Multimedia Mike — General

  My new EeePC 1201PN netbook has 2 GB of RAM. Call me shortsighted but I feel like “that ought to be enough for me”. I’m not trying to claim that it ought to be enough for everyone. I am, however, questioning the utility of swap space for those skilled in the art of computing.

  
  
  Technology marches on : This ancient 128 MB RAM module is larger than my digital camera’s battery charger… and I just realized that comparison doesn’t make any sense
  

  Does anyone else have this issue ? It has gotten to the point where I deliberately disable swap partitions on Linux desktops I’m using ('swapoff -a'), and try not to allocate a swap partition during install time. I’m encountering Linux installers that seem to be making it tougher to do this, essentially pleading with you to create a swap partition– “Seriously, you might need 8 total gigabytes of virtual memory one day.” I’m of the opinion that if 2 GB of physical memory isn’t enough for my normal operation, I might need to re-examine my processes.

  In the course of my normal computer usage (which is definitely not normal by the standard of a normal computer user), swap space is just another way for the software to screw things up behind the scenes. In this case, the mistake is performance-related as the software makes poor decisions about what needs to be kept in RAM.

  And then there are the netbook-oriented Linux distributions that insisted upon setting aside as swap 1/2 gigabyte of the already constrained 4 gigabytes of my Eee PC 701′s on-board flash memory, never offering the choice to opt out of swap space during installation. Earmarking flash memory for swap space is generally regarded as exceptionally poor form. To be fair, I don’t know that SSD has been all that prevalent in netbooks since the very earliest units in the netbook epoch.

  Am I alone in this ? Does anyone else prefer to keep all of their memory physical in this day and age ?

• Multiprocess FATE Revisited

  26 juin 2010, par Multimedia Mike — FATE Server, Python

  I thought I had brainstormed a simple, elegant, multithreaded, deadlock-free refactoring for FATE in a previous post. However, I sort of glossed over the test ordering logic which I had not yet prototyped. The grim, possibly deadlock-afflicted reality is that the main thread needs to be notified as tests are completed. So, the main thread sends test specs through a queue to be executed by n tester threads and those threads send results to a results aggregator thread. Additionally, the results aggregator will need to send completed test IDs back to the main thread.

  
  
  

  But when I step back and look at the graph, I can’t rationalize why there should be a separate results aggregator thread. That was added to cut down on deadlock possibilities since the main thread and the tester threads would not be waiting for data from each other. Now that I’ve come to terms with the fact that the main and the testers need to exchange data in realtime, I think I can safely eliminate the result thread. Adding more threads is not the best way to guard against race conditions and deadlocks. Ask xine.

  
  
  

  I’m still hung up on the deadlock issue. I have these queues through which the threads communicate. At issue is the fact that they can cause a thread to block when inserting an item if the queue is "full". How full is full ? Immaterial ; seeking to answer such a question is not how you guard against race conditions. Rather, it seems to me that one side should be doing non-blocking queue operations.

  This is how I’m planning to revise the logic in the main thread :

  test_set = set of all tests to execute
  tests_pending = test_set
  tests_blocked = empty set
  tests_queue = multi-consumer queue to send test specs to tester threads
  results_queue = multi-producer queue through which tester threads send results
  while there are tests in tests_pending :
    pop a test from test_set
    if test depends on any tests that appear in tests_pending :
      add test to tests_blocked
    else :
      add test to tests_queue in a non-blocking manner
      if tests_queue is full, add test to tests_blocked
    while there are results in the results_queue :
  
      get a result from result_queue in non-blocking manner
  
      remove the corresponding test from tests_pending
  if tests_blocked is non-empty :
  
    sleep for 1 second
  
    test_set = tests_blocked
  
    tests_blocked = empty set
  
  else :
  
    insert n shutdown signals, one from each thread
  go to the top of the loop and repeat until there are no more tests
  while there are results in the results_queue :
  
    get a result from result_queue in a blocking manner
  

  Not mentioned in the pseudocode (so it doesn’t get too verbose) is logic to check whether the retrieved test result is actually an end-of-thread signal. These are accounted and the whole test process is done when one is received for each thread.

  On the tester thread side, it’s safe for them to do blocking test queue retrievals and blocking result queue insertions. The reason for the 1-second delay before resetting tests_blocked and looping again is because I want to guard against the situation where tests A and B are to be run, A depends of B running first, and while B is running (and happens to be a long encoding test), the main thread is spinning about, obsessively testing whether it’s time to insert A into the tests queue.

  It all sounds just crazy enough to work. In fact, I coded it up and it does work, sort of. The queue gets blocked pretty quickly. Instead of sleeping, I decided it’s better to perform the put operation using a 1-second timeout.

  Still, I’m paranoid about the precise operation of the IPC queue mechanism at work here. What happens if I try to stuff in a test spec that’s a bit too large ? Will the module take whatever I give it and serialize it through the queue as soon as it can ? I think an impromptu science project is in order.

  big-queue.py :

  PLAIN TEXT

  PYTHON :

  1. # !/usr/bin/python
  2.  
  3. import multiprocessing
  4. import Queue
  5.  
  6. def f(q) :
  7.   str = q.get()
  8.   print "reader function got a string of %d characters" % (len(str))
  9.  
  10. q = multiprocessing.Queue()
  11. p = multiprocessing.Process(target=f, args=(q,))
  12. p.start()
  13. try :
  14.   q.put_nowait(’a’ * 100000000)
  15. except Queue.Full :
  16.   print "queue full"

  $ ./big-queue.py
  reader function got a string of 100000000 characters
  

  Since 100 MB doesn’t even make it choke, FATE’s little test specs shouldn’t pose any difficulty.