Hi, > -----Original Message----- > From: Brad Clements [mailto:[EMAIL PROTECTED]] > Sent: Montag, 4. Februar 2002 16:48 > To: Mensing, Joerg; [EMAIL PROTECTED] > Subject: RE: Porting to Novell NetWare > > > On 4 Feb 2002 at 10:30, Mensing, Joerg wrote: > > > > Any interest in a port to Novell NetWare? > > > > > Do you know any open source project, that is not interested > in other ports > > as long as it does not produce too much extra efforts ;-) > > Well, I suppose the "extra effort" also depends on the person > doing the port. :-( > thats the tricky thing about man month ;-)
> > > > What kind of memory requirements does the kernel have? > > > > > It uses shared memory for communication and for monitoring console > > activities. The amount of memory strongly depends on parameters for > > CACHESIZE. > > Are you using mmap or work-alike, so that different processes > (not threads) access the > same memory block? Since Version 7.2.0 SAPDB kernel is a multithreaded program on NT and UNIX! The complete data cache is allocated from heap via malloc(). There is no need to allocate via mmap() or shmget() except for our in-memory tracing buffer, which is dumped by a watchdog process in case of a crash on UNIX and our 'kernel_global_storage structure, that contains task control blocks and queues. This are exported to console program x_cons via a shared memory segment, for faster monitoring. > > Is the kernel a monolithic process with multiple threads, or > multiple processes? I ask > this from the Win32 perspective, rather than the Linux perspective. True on both OS, but on Linux it does not look like it. The reason is that LINUX does not really support POSIX threads, but simulates it using '_clone()' processes. These processes are a specialty that share most resources except for the process id! So in LINUX the getpid() call will give you different ids in different threads... There are also some limitations for signal handling... I am talking here about libpthread.so. A pure user level implementation of pthreads would not be scaling on multi processor systems and you always have these ugly blocking system call problems especially with semaphores... > > > All new stuff is C++ coding. > > Exceptions yes (unfortunatly since they got a bad > reputation due to lots of > > compiler features...) RTTI currently forbidden - when > coding startet on AIX > > there was just CSet++ and we uses the minimum feature set (i.e. no > > <dynamic_cast>...). Anyhow it would increase the size of EACH class > > instance, even those that do not need RTTI at all... > > Well, this might knock off this idea completely. Metrewerks > is the compiler of choice for > NetWare right now, I'll have to check and see how well it can > handle this on NetWare. > The NetWare OS has limitations beyond those of the compiler. > > > > > For the C client library. Is multi-threading supported > (win32, linux)? > > Yes for ODBC it is used, but the runtime calls are serialized by an > > extrernal mutex. > > Are you saying that the only client access on Win32 is via > ODBC, and that there isn't a > native DLL available that works "at a lower layer"? > On no. There is a native DLL, but on UNIX it is not multithread save. > I'm thinking specifically of Python and Zope, where we'd like > to process multiple > simultaneous database requests (not serialized) on both > Windows and Linux. > I have to check with Daniel about the python and perl support libraries. He is back tomorrow. > > Also, the client would have to work on NetWare too, so > probably the Linux client library > could be ported. > > > By the way, Potsdam bei Berlin,Germany is not that fare away ;-) > > Ah, our "sister city". ;-) > > > > Brad Clements, [EMAIL PROTECTED] (315)268-1000 > http://www.murkworks.com (315)268-9812 Fax > netmeeting: ils://ils.murkworks.com AOL-IM: BKClements > CU jrg _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
