From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 4 Jun 2002 04:27:24 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 233 ************************************************** Monday 03 June 2002 Number 233 ************************************************** Subjects for today 1 Re: Fnodes : Jack Troughton 2 Re: Fnodes : Jack Troughton 3 Re: Fnodes : Jack Troughton 4 Fnodes : John Poltorak 5 Re: Fnodes : John Poltorak 6 Re: Fnodes : Christian Hennecke" 7 Re: Fnodes : John Poltorak 8 Re: db.lib : John Poltorak 9 Re: Building BZIP2 with OpenWatcom : Roman Trunov 10 Re: Building BZIP2 with OpenWatcom : John Poltorak 11 Re: Building BZIP2 with OpenWatcom : G. W. Ulrich Sieveking" 12 Re: Building BZIP2 with OpenWatcom : Sebastian Wittmeier (ShadoW)" 13 Re: Perl v5.8.0 : Andreas Buening **= Email 1 ==========================** Date: Tue, 04 Jun 2002 08:22:18 -0400 From: Jack Troughton Subject: Re: Fnodes John Poltorak wrote: > How does one go about handling FNODES when porting a Unix program to OS/2? Ask Jan van Wijk. He's the guy who will know your answer if anybody does. Is he on the mail list? If not, why don't you try writing him directly? I assume you're asking about phpa, right? From the description, it looks like it's probably not very portable... it looks like it bypasses the normal system file calls to do its thing. This would make it pretty specific to extfs(2). You're probably further ahead taking the algorithm (which is described on their web page... I can't see how they can complain about someone using it) and applying it to scripts on the OS/2 system. It looks like the scripts are basically stored in a ram cache, and with a longest since use algorithm to decide what stays in there. The place where reading the blocks comes in is deciding whether a particular script needs to be reloaded because it's been modified... and it uses this method to cut down on the overhead associated with the usual file read stuff. You know what would be cool? If you could start a program like php and feed it script names to execute on stdin, with output going to stdout. Stick the scripts in a ramdisk (I mean, how big can they be?) and you've got a very fast solution. -- ------------------------------------------------------------------- * Jack Troughton jake at consultron.ca * * http://consultron.ca irc.ecomstation.ca * * Laval Qu‚bec Canada news://news.consultron.ca * ------------------------------------------------------------------- **= Email 2 ==========================** Date: Tue, 04 Jun 2002 11:28:50 -0400 From: Jack Troughton Subject: Re: Fnodes John Poltorak wrote: > On Tue, Jun 04, 2002 at 08:22:18AM -0400, Jack Troughton wrote: > >> John Poltorak wrote: >> >>> How does one go about handling FNODES when porting a Unix program >>> to OS/2? >> >> Ask Jan van Wijk. He's the guy who will know your answer if anybody >> does. > >> Is he on the mail list? If not, why don't you try writing him >> directly? >> >> I assume you're asking about phpa, right? > > Yes, that is what sparked off the question, although I don't know > anything about the program itself. I saw your posts on usenet about it, and looked it up. >> From the description, it looks like it's probably not very >> portable... it looks like it bypasses the normal system file calls >> to do its thing. This would make it pretty specific to extfs(2). > > If that is the case, it would probably be better to get the author to > make it more generic and use the existing file system. I don't think that's possible... from the description, it's the extreme specificity to a particular platform and file system (linux, ext2fs) that gives it its speed. >> You're probably further ahead taking the algorithm (which is >> described on their web page... I can't see how they can complain >> about someone using it) and applying it to scripts on the OS/2 >> system. It looks like the scripts are basically stored in a ram >> cache, and with a longest since use algorithm to decide what stays >> in there. > > Can't you achieve the same thing with a big cache using HPFS386 or > JFS? ... just wondered if it's possible to lock anything in cache and > prevent it from getting discarded... AFAIK, it's not possible to lock things in cache; hence things like ramfs. It looks like phpa keeps a copy running (so as to avoid the cost associated with starting/stopping the executable) and gets it to process the script... and speeds up access to the script by keeping it in a ram cache. That's all pretty straightforward. The thing is, you have to check each time it runs to ensure that the version of the script you're running is in fact the right version... which will cost you if you have to go to the filesystem each time. It looks (according to the description on the webpage) that it actually looks at the disk directly by keeping a record of the block number with the script so as to avoid all the overhead associated with a normal call to the filesystem, so as to minimise that cost as much as possible. >> The place where reading the blocks comes in is deciding whether a >> particular script needs to be reloaded because it's been >> modified... and it uses this method to cut down on the overhead >> associated with the usual file read stuff. >> >> You know what would be cool? If you could start a program like php >> and feed it script names to execute on stdin, with output going to >> stdout. > > > How about redirecting stdout to nul? Doesn't php normally direct its output to stdout? That is... you feed a page with embedded scripts in, and out comes a page with the scripts processed, to be picked up by the server and fed to the client? php < somefile.php > somefile.html should result in a file on your hard disk called somefile.html with the processed page in it? >> Stick the scripts in a ramdisk (I mean, how big can they be?) and >> you've got a very fast solution. > > Wouldn't it be just as fast (maybe faster) if the scripts were > cached? Yes... but (under current conditions) a ramdisk *guarantees* that the script is in ram, while the system file cache doesn't. -- ------------------------------------------------------------------- * Jack Troughton jake at consultron.ca * * http://consultron.ca irc.ecomstation.ca * * Laval Qu‚bec Canada news://news.consultron.ca * ------------------------------------------------------------------- **= Email 3 ==========================** Date: Tue, 04 Jun 2002 11:43:49 -0400 From: Jack Troughton Subject: Re: Fnodes Christian Hennecke wrote: >>>You know what would be cool? If you could start a program like php and >>>feed it script names to execute on stdin, with output going to stdout. >> > > Isn't that what the CGI version of PHP does? AFAIK, it executes separately each time you call a page. I don't believe that the CGI interface spec permits script interpreters to function as a daemon. This could depend on the web server in question, of course. -- ------------------------------------------------------------------- * Jack Troughton jake at consultron.ca * * http://consultron.ca irc.ecomstation.ca * * Laval Qu‚bec Canada news://news.consultron.ca * ------------------------------------------------------------------- **= Email 4 ==========================** Date: Tue, 4 Jun 2002 11:54:00 +0100 From: John Poltorak Subject: Fnodes How does one go about handling FNODES when porting a Unix program to OS/2? -- John **= Email 5 ==========================** Date: Tue, 4 Jun 2002 15:39:15 +0100 From: John Poltorak Subject: Re: Fnodes On Tue, Jun 04, 2002 at 08:22:18AM -0400, Jack Troughton wrote: > John Poltorak wrote: > > How does one go about handling FNODES when porting a Unix program to OS/2? > > Ask Jan van Wijk. He's the guy who will know your answer if anybody does. > > Is he on the mail list? If not, why don't you try writing him directly? > > I assume you're asking about phpa, right? Yes, that is what sparked off the question, although I don't know anything about the program itself. > From the description, it looks > like it's probably not very portable... it looks like it bypasses the > normal system file calls to do its thing. This would make it pretty > specific to extfs(2). If that is the case, it would probably be better to get the author to make it more generic and use the existing file system. > You're probably further ahead taking the algorithm > (which is described on their web page... I can't see how they can > complain about someone using it) and applying it to scripts on the OS/2 > system. It looks like the scripts are basically stored in a ram cache, > and with a longest since use algorithm to decide what stays in there. Can't you achieve the same thing with a big cache using HPFS386 or JFS? ... just wondered if it's possible to lock anything in cache and prevent it from getting discarded... > The place where reading the blocks comes in is deciding whether a > particular script needs to be reloaded because it's been modified... and > it uses this method to cut down on the overhead associated with the > usual file read stuff. > > You know what would be cool? If you could start a program like php and > feed it script names to execute on stdin, with output going to stdout. How about redirecting stdout to nul? > Stick the scripts in a ramdisk (I mean, how big can they be?) and you've > got a very fast solution. Wouldn't it be just as fast (maybe faster) if the scripts were cached? > -- > ------------------------------------------------------------------- > * Jack Troughton jake at consultron.ca * > * http://consultron.ca irc.ecomstation.ca * > * Laval Qbec Canada news://news.consultron.ca * > ------------------------------------------------------------------- -- John **= Email 6 ==========================** Date: Tue, 04 Jun 2002 17:33:35 +0200 (CEST) From: "Christian Hennecke" Subject: Re: Fnodes >> You know what would be cool? If you could start a program like php and >> feed it script names to execute on stdin, with output going to stdout. Isn't that what the CGI version of PHP does? Christian Hennecke **= Email 7 ==========================** Date: Tue, 4 Jun 2002 17:47:08 +0100 From: John Poltorak Subject: Re: Fnodes On Tue, Jun 04, 2002 at 11:28:50AM -0400, Jack Troughton wrote: > > >> You're probably further ahead taking the algorithm (which is > >> described on their web page... I can't see how they can complain > >> about someone using it) and applying it to scripts on the OS/2 > >> system. It looks like the scripts are basically stored in a ram > >> cache, and with a longest since use algorithm to decide what stays > >> in there. > > > > Can't you achieve the same thing with a big cache using HPFS386 or > > JFS? ... just wondered if it's possible to lock anything in cache and > > prevent it from getting discarded... > > AFAIK, it's not possible to lock things in cache; hence things like ramfs. One thing I have never known how to do was display the current contents of cache. Is there any way to do this? Is it possible to tell whether a particular invocation of a program involves loading it from disk or using a cached copy? On occasion I run cache386 and it tells me that the cache hit rate is 96% or over. If any scripts are frequently used, I'm sure they would remain in cache, given sufficient memory and cache size. I presume the OS can be relied upon to refresh files in cache which have been updated. > It looks like phpa keeps a copy running (so as to avoid the cost > associated with starting/stopping the executable) and gets it to process > the script... and speeds up access to the script by keeping it in a ram > cache. That's all pretty straightforward. The thing is, you have to > check each time it runs to ensure that the version of the script you're > running is in fact the right version... which will cost you if you have > to go to the filesystem each time. In real world usage, how much does this matter? How often will these scripts get updated once productionised? It should be possible to devise some way that any required scripts are always kept in memory. Doesn't EMXLOAD do something like this? > It looks (according to the > description on the webpage) that it actually looks at the disk directly > by keeping a record of the block number with the script so as to avoid > all the overhead associated with a normal call to the filesystem, so as > to minimise that cost as much as possible. IMV the usefulness of such a feature does look overstated, although it would be nice to have some empirical data to base a proper judgement on... Having said that, I have no real idea how efficient OS/2 cacheing is. I'd be interested in any test results anyone has ever come across. > -- > ------------------------------------------------------------------- > * Jack Troughton jake at consultron.ca * > * http://consultron.ca irc.ecomstation.ca * > * Laval Qbec Canada news://news.consultron.ca * > ------------------------------------------------------------------- -- John **= Email 8 ==========================** Date: Tue, 4 Jun 2002 18:04:42 +0100 From: John Poltorak Subject: Re: db.lib On Mon, Jun 03, 2002 at 01:22:53PM -0400, Henry Sobotka wrote: > John Poltorak wrote: > > > > I get a lot of errors like this in POPUPLOG.OS2:- > > > > 06-03-2002 17:31:16 SYS2070 PID 90c6 TID 0001 Slot 00bf > > C:\EVAL\PERL-5.8\PERL-5.8.0-RC1\T\PERL.EXE > > DB_FILHA->PERLB12E.malloc > > 127 > > Those generally mean a wrong version of the DLL is being loaded because > it comes first in LIBPATH or whatever. There were only two instances of PERLB12E.DLL and they were identical. I didn't have these errors when I used a different version of db.lib so I can only conclude that it is this current version of db.lib which has caused these problems. Unfortunately the other db.lib did not contain dbopen for some reason unknown to me... > h~ -- John **= Email 9 ==========================** Date: Tue, 4 Jun 2002 19:42:25 +0400 From: Roman Trunov Subject: Re: Building BZIP2 with OpenWatcom **= Email 10 ==========================** Date: Tue, 4 Jun 2002 20:00:37 +0100 From: John Poltorak Subject: Re: Building BZIP2 with OpenWatcom On Tue, Jun 04, 2002 at 07:42:25PM +0400, Roman Trunov wrote: > Hello John, Hi Roman, I noticed that you cc'd a copy of the msg to the list. Unfortunately, for some reason, the cc'd copy gets sent out as a blank msg to the list by my maiing list manager, so apologies to anyone who got a blank mail from the list and wondered why... > > JP> I heard it ws fairly straightforward building BZIP2 with > JP> OpenWatcom... > > Yes, I just emulated Windows build with compiler options. Even > don't modified source, just created dummy windows.h with some > #define's. Well it's good to know that Watcom can be used relatively easily. > JP> It would be interesting to see how it compares against one built > JP> with gcc. > > Watcom is not very good in speed optimization. It can generate small > code and, as side effect, this size-optimized code can even work > faster then speed-optimized code! (especially when lot on functions > calls involved). But, alas, not in bzip's case... That's interesting. Is there any chance of you reporting your experience on the openwatcom newsgroup? > There is somewhere (on hobbes?) a bzip built with IBM VAC. It's about > 20% faster then my Watcom's build. If you want benchmarks, compare > this version against gcc's. I wouldn't really want to start using VAC in this situation because it is not freely available, and is likely to be discontinued in the near future with no further support offerred. I'm more interested in the relative merits of open source solutions and how well OpenWatcom compares with gcc. > Best regards, > Roman mailto:stream at proxyma.ru -- John **= Email 11 ==========================** Date: Tue, 04 Jun 2002 21:29:16 +0200 From: "G. W. Ulrich Sieveking" Subject: Re: Building BZIP2 with OpenWatcom John Poltorak schrieb: > > I wouldn't really want to start using VAC in this situation because it is > not freely available, and is likely to be discontinued in the near future > with no further support offerred. VAC++ has been withdrawn from marketing in April 2001 and it's end of service date was 2001/09/28. Greetings, Ulrich **= Email 12 ==========================** Date: Tue, 04 Jun 2002 21:58:46 +0200 (CEST) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: Building BZIP2 with OpenWatcom On Tue, 04 Jun 2002 21:29:16 +0200, G. W. Ulrich Sieveking wrote: >VAC++ has been withdrawn from marketing in April 2001 and it's end of >service date was 2001/09/28. Currently only private fixes are released. From a VOICE message: >Private fixes for IBMVACPP 3.65 provided by the IBM Mozilla team > >Fixes for optimizer (various optimzer bugs) >Fixes for linker (some objects couldn't be linked in a certain order) >Fixes for runtime (daylight savings time doesn't work properly > >ftp://service.boulder.ibm.com/ps/products/warpzilla/vacpp365fix.zip Sebastian **= Email 13 ==========================** Date: Tue, 04 Jun 2002 23:17:32 +0200 From: Andreas Buening Subject: Re: Perl v5.8.0 Lyn St George wrote: > > On Sun, 02 Jun 2002 15:26:48 +0200, Andreas Buening wrote: [snip] > >Do you have an old gcc2952m.dll (or a similar dll) on > >your system that is used by your Unix tools? There are > >some broken versions outside. > >Problem: Right after a reboot everything is okay, but > >after a while more and more EMX programs run out of > >memory. You can solve this temporarily by unloading > >running programs from memory, but on the long term > >you have to reboot. > >Solution: Install fixed versions of those libraries. > > Aha .. running 'which -la gcc*' finds 5 of the little devils. > Deactivating them all breaks several things, including > gcc-2.95.3 itself. Maybe it's when I changed from 2.81 that > this problem started. So now to apply the solution. > Many thanks. Not really. All applications that have been compiled with gcc 2.95 or higher without the "-lgcc" option use these dlls. You have to update them (or to recompile all programs that use them). You might find patched versions of them on ftp.unixos2.com (but I'm not sure). I have only patched versions of gcc2952m.dll and gcc2952s.dll on my computer (which are used by pgcc 2.95.3). I can send them to you by mail if you can't find them otherwise. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Redmond where the Shadows lie.