Thread: [idms-dbma-devel]Modular changes
Status: Pre-Alpha
Brought to you by:
nkukard
Menu
▾
▴
idms-dbma-devel
|
From: Nigel K. <nk...@lb...> - 2005-04-26 06:57:51
Attachments:
signature.asc
|
Hi Guys, I propose the following changes to achieve our goals... Goals: 1. Our server package must beable to use the networking technologies, select(), poll(), epoll() ... etc 2. Our server package must also beable to use either pre-forking, threading or the current c10k design 3. Our server package must beable to use both local disk and NFS to store and retrieve data, remembering an open() on NFS CAN block no matter what Changes to be made for the above points: 1. The only way we can implement different notificatoin systems is to have an abstraction API. 2. Different connection handling technologies will be implemented as different modules, also with an abstraction API. This will allow us to support the best means of handling notifications under systems like bsd, solaris, linux ... etc. 3. Handling disk IO will be done the same, an abstraction API and modules... this will allow us to intercept all NFS disk IO to a specific path location and direct it to the module which can handle it in a sane way. None of the above points have to be implemented anytime soon, I'm going to start work on implementing the diskIO engine which will handle local disk IO and the abstraction layer therefore. The location of this will be in modules/diskIO/localdisk/. The abastraction layer will be created in modules/diskIO/. Anand, when you finished with socklib.c we must speak about moving that thread function I told you about into modules/networkIO/c10k... don't worry about it now. This will allow us to keep only socket related stuff in socklib.c. If anyone has any suggestions, plz let me know. -Nigel -- Nigel Kukard, PhD CompSc (Chief Executive Officer) Linux Based Systems Design Web: www.lbsd.net Email: nk...@lb... Tel: (+27) 023 349 8000 Cell: (+27) 082 333 3723 Fax: (+27) 023 349 1395 Support: 086 747 7600 Address: LIGT House, 2 Klipdrift Rd, Rawsonville Linux Systems Design & Technology Solutions The best language to use is the language that was designed for what you want to use it for. ===================================================================== Disclaimer ---------- The contents of this message and any attachments are intended solely for the addressee's use and may be legally privileged and/or confidential information. This message may not be retained, distributed, copied or used if you are not he addressee of this message. If this message was sent to you in error, please notify the sender immediately by reply e-mail and then destroy the message and any copies thereof. Opinions, conclusions and other information in this message may be personal to the sender and is not that of Linux Based Systems Design, LinuxRulz or any of it's subsideries, associated companies or principals and is therefore not endorsed by Linux Based Systems Design or LinuxRulz. Due to e-maill communication being insecure, Linux Based Systems Design and LinuxRulz do not guarantee confidentiality, security, accuracy or performance of the e-mail. Any liability for viruses is excluded to the fullest extent. |
|
From: anand c. <ana...@gm...> - 2005-04-26 11:53:19
|
Hi I am still working on socklib.c , it will require few days more(hopefully 2-3 days) . Still have some quries,will contat u on messenger.. Anand On 4/26/05, Nigel Kukard <nk...@lb...> wrote: > Hi Guys, >=20 > I propose the following changes to achieve our goals... >=20 > Goals: > 1. Our server package must beable to use the networking technologies, > select(), poll(), epoll() ... etc > 2. Our server package must also beable to use either pre-forking, > threading or the current c10k design > 3. Our server package must beable to use both local disk and NFS to > store and retrieve data, remembering an open() on NFS CAN block no > matter what >=20 > Changes to be made for the above points: > 1. The only way we can implement different notificatoin systems is to > have an abstraction API. > 2. Different connection handling technologies will be implemented as > different modules, also with an abstraction API. This will allow us to > support the best means of handling notifications under systems like bsd, > solaris, linux ... etc. > 3. Handling disk IO will be done the same, an abstraction API and > modules... this will allow us to intercept all NFS disk IO to a specific > path location and direct it to the module which can handle it in a sane w= ay. >=20 > None of the above points have to be implemented anytime soon, I'm going > to start work on implementing the diskIO engine which will handle local > disk IO and the abstraction layer therefore. The location of this will > be in modules/diskIO/localdisk/. The abastraction layer will be created > in modules/diskIO/. >=20 > Anand, when you finished with socklib.c we must speak about moving that > thread function I told you about into modules/networkIO/c10k... don't > worry about it now. This will allow us to keep only socket related stuff > in socklib.c. >=20 > If anyone has any suggestions, plz let me know. >=20 > -Nigel >=20 > -- > Nigel Kukard, PhD CompSc > (Chief Executive Officer) > Linux Based Systems Design > Web: www.lbsd.net Email: nk...@lb... > Tel: (+27) 023 349 8000 Cell: (+27) 082 333 3723 > Fax: (+27) 023 349 1395 Support: 086 747 7600 > Address: LIGT House, 2 Klipdrift Rd, Rawsonville > Linux Systems Design & Technology Solutions >=20 > The best language to use is the language that was designed for > what you want to use it for. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Disclaimer > ---------- > The contents of this message and any attachments are intended > solely for the addressee's use and may be legally privileged and/or > confidential information. This message may not be retained, > distributed, copied or used if you are not he addressee of this > message. If this message was sent to you in error, please notify > the sender immediately by reply e-mail and then destroy the message > and any copies thereof. >=20 > Opinions, conclusions and other information in this message may be > personal to the sender and is not that of Linux Based Systems Design, > LinuxRulz or any of it's subsideries, associated companies or > principals and is therefore not endorsed by Linux Based Systems > Design or LinuxRulz. Due to e-maill communication being insecure, > Linux Based Systems Design and LinuxRulz do not guarantee > confidentiality, security, accuracy or performance of the e-mail. > Any liability for viruses is excluded to the fullest extent. >=20 >=20 > |
Thanks for helping keep SourceForge clean.
X