Temos uma política bastante restritiva em relação a anúncios no site. Eles nunca irão te atrapalhar!
Além disso, usamos banners para lhe informar de assuntos importantes. Os bloqueadores de anúncios impedem que esses banners sejam visualizados.
Sendo assim, para continuar, é importante que você desligue o bloqueador de anúncio e recarregue a página. Obrigado!

Notícias

até
[16/12/03] Projeto Vulcan!

Jim Starkey, o criador do InterBase e atualmente casado com Ann Harrison, uma das proprietárias da IBPhoenix anunciou hoje na lista de discussão de firebird-devel que ele estará desenvolvendo nos próximos 3 meses uma versão derivada do FB 1.5 com as características de ser thread-safe e de rodar em processadores de 64bits - o projeto está sendo chamado de Vulcan. Isso vai gerar várias mudanças estruturais em algumas partes do código do Firebird e a boa notícia é que essas mudanças serão incorporadas no próprio Firebird assim que o projeto estiver finalizado! Veja a mensagem de anúncio:

I've been hired by IBPhoenix to product a 64 bit, SMP-friendly reference port for Firebird.  The formal deliverable will be for 64 Sparc, though I plan to produce AMD64/Opteron versions for WinXP and Linux on the way.  I'm calling it Project Vulcan (I wanted to call it IBAlbuquerque but Mozilla is already using the name).

The requirement is for a thread-safe, embeddable, 64 bit versions capable of 3X performance on a four processor system (or run out of disk bandwidth trying) in a three month period.  The resulting code will be released under the standard Interbase Public License.

Given the aggressive schedule, I'm going to deviate somewhat from the normal development methodology.  I'm starting with the Firebird 1.5 code base (as of last Thursday), but will be working out of a private CVS tree.  If folks are interested, I'm will to grant read-only access to the tree as long as things don't get too crazy.  The plan is for IBPhoenix to re-integrate the code bases at the end of the project.  If there are volunteers, it may be possible feasible to migrate changes from Vulcan to Firebird enroute, but the schedule dictates that I work without external dependencies.  My goal is to produce a working, maintainable, fast, lightweight system.  If folks want to have a brawl over the political correctness of my code, they can do so after I'm done.  Ann has been designated by IBPhoenix to lead the reintegration phase.

I'd be more than delighted to talk and argue about the project as we go, treating the process as an extended masters class.  If folks are happy, we can do it here on the developers list.  If not, I'll start up an ad hoc list for the duration of the project.

My primary development platforms will be WinXP (32 and 64) under MSVC with frequent checkouts on Linux (RedHat 32 bit and probably Suse 64 bit), and finally Solaris.

Subject to delivery of my development hardware, my plan of attack is:

  1. Clean up the layering: server / Y-valve / subsystems.  I will rewrite why.c to use a canonical C++ class as the sole interface to data management systems, which can be either linked or dynamically loaded.  There will be only one Y-valve component shared by client and server processes.  During the rewrite I will sanitize the code base of modules not under the Interbase Public License.
  2. Introduce thread synchronization technology (fast lock shared/exclusive monitors)  from Netfrastructure.
  3. Remove dead code from the Firebird code base.  GDS_VAL, WAL, thread_enter/thread_exit are all endangered.
  4. Reconstitute major engine components as proper C++ objects.  The cache manager (CCH) is the priority candidate.
  5. Add monitors for major data structures.  Note: delivery requirements dictates 64 development version before thread safety, so there is a race condition between hardware delivery and thread safety.  The monitor code will be in mainline, not conditionalized.
  6. 64 bit compilation and execution on Microsoft, gcc, and probably Sun compilers.  Crap and dead conditionals that get in my way will be dealt with ruthlessly.
Cleanups, encapsulation, simplification, and exception handling will happen as needed.  If the std:: crud gets in my way, I'll replace it with something lighter weight and more portable.  I generally restrict myself a C++ subset roughly consistent with Java, so again, if provoked, I'll substitute straightforward code for arcanity (gosh, until I read the Firebird code, I didn't even know you could call an object's destructor).

I think this is going to be fun.  And I think it will be a bang-up product at the end.  I think the AMD 64 bit architecture is the best thing since the death of the PDP-11.

Jim Starkey
Netfrastructure, Inc.
978 526-1376

Compartilhe essa notícia: