Quantcast
Channel: Jason Andrews Blog
Viewing all articles
Browse latest Browse all 33813

RE: How to invoke the geSaveAllForm?

$
0
0
It’s probably more of a UNIX-style approach to have a set of cooperating separate processes which are focussed on an individual task. So for a long time there have been external processes that allow the a task such as this to be done in parallel - and even from batch without needing the whole Virtuoso infrastructure to be running to generate a stream file; there are also netlisters that run in the background too. Now of course, multi-threaded applications are a far more common paradigm and parallelism could be achieved that way (although even assuming that this was done, there would need to be some locking to prevent database changes in memory during a stream out; that’s also glossing over the frankly enormous task of making the whole of Virtuoso thread-safe). The stream out from Virtual memory is a relatively recent addition (it’s still been there for some time), and not the default because we have to preserve existing default behaviour - and some customers actually want to ensure that the data gets saved on disk because otherwise you can end up verifying a design - effectively taping out the stream file for manufacture, but accidentally not save the database. It’s always very hard to change defaults when you have a widespread user base; it’s never going to be OK to change such a default unilaterally for all customers. The restrictions on available functions in pcells is longstanding, and not just because of the stream interface. Some of the physical verification tools could read the database directly (e.g. Dracula, Diva, Assura etc) and if these are running in batch (which makes sense, because you may want to run on a remote machine), they’d have to have access to the whole of Virtuoso if arbitrary SKILL were needed. Similarly the ITKDB capability where applications can also interface to the database using C code - this also provides database access only rather than the whole of Virtuoso. Historically we used to even have multiple different executables which had different capabilities to try to optimise memory use when memory was far more expensive than it is nowadays (we now have a single virtuoso executable, but we used to have lots of different variants in the past). So the reasons are historical, infrastructural, and changing it is not as simple as it might appear. Regards, Andrew.

Viewing all articles
Browse latest Browse all 33813

Trending Articles