peter@sugar.hackercorp.com (Peter da Silva) (12/03/89)
In article <8787@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > Static limits are a bad thing, period. MS-DOS even makes you tell it how > many files you'll allow to be open at once. Apparently OS/2 suffers from > the same faulty thinking... Like the limit of 32 SigBits for an AmigaOS task? The Amiga isn't immune to the static limit problem. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "Really, a video game is nothing more than a Skinner box." -- Peter Merel <pete@basser.oz>
usenet@cps3xx.UUCP (Usenet file owner) (12/04/89)
In article <4659@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <8787@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >> Static limits are a bad thing, period. MS-DOS even makes you tell it how >> many files you'll allow to be open at once. Apparently OS/2 suffers from >> the same faulty thinking... > >Like the limit of 32 SigBits for an AmigaOS task? The Amiga isn't immune to >the static limit problem. Yes but sigbits can be shared between multiple event generators. It is somewhat harder to share file handles between multiple files :-) Joe Porkka porkka@frith.egr.msu.edu
peter@sugar.hackercorp.com (Peter da Silva) (12/04/89)
In article <5649@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes: > In article <4659@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >In article <8787@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > >> Static limits are a bad thing, period. MS-DOS even makes you tell it how > >> many files you'll allow to be open at once. Apparently OS/2 suffers from > >> the same faulty thinking... > >Like the limit of 32 SigBits for an AmigaOS task? The Amiga isn't immune to > >the static limit problem. > Yes but sigbits can be shared between multiple event generators. > It is somewhat harder to share file handles between multiple files :-) struct FileHandle { struct FileHandle *next; struct FileHandle *prev; FILE *fp; char *name; char *mode; off_t offset; int valid; long used; }; struct FileHandle *fhroot; /* circular doubly-linked list */ long seq = 0; struct FileHandle *fhopen(file, mode) char *file, *mode; { struct FileHandle *fh; fh = new(FileHandle); if(!(fh->fp = fopen(name, mode))) { recover_fp(); if(!(fh->fp = fopen(name, mode))) { dispose(FileHandle); return 0; } } fh->name = clone(name); fh->mode = clone(mode); fh->used = seq++; insert(fh, fhroot); return fh; } fhclose(fh) struct FileHandle *fh; { FILE *fp; remove(fh); fp = fh->fp; dispose(fh->name); dispose(fh->mode); dispose(fh); return fp?fclose(fp):SUCCESS; } fhread(fh, bytes, count) { if(!fh->valid) return 0; if(!fh->fp) { recover_fp(); if(!(fh->fp = fopen(fh->name, fh->mode))) { fh->valid = 0; return 0; } fseek(fh->fp, fh->seek, 0); } fh->used = seq++; return fread(bytes, count, 1, fh->fp); } recover_fp() { Find fh with lowest fh_seq; fh->offset = ftell(fh->fp); fclose(fh->fp); fh->fp = 0; } ... and so on. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "Really, a video game is nothing more than a Skinner box." -- Peter Merel <pete@basser.oz>
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (12/05/89)
You made the point very well. It really is harder to share one filehandle among many files than to share one sigbit. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...uunet!pdn!jc3b21!fgd3
peter@sugar.hackercorp.com (Peter da Silva) (12/07/89)
In article <807@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > You made the point very well. It really is harder to share one filehandle > among many files than to share one sigbit. I've done both (share file descriptors and share sigbits), and I disagree. The code I included (you did read it, didn't you) was more than just sharing one FD. It automatically adjusted to the number of FDs available, and used a LRU scheme to treat the available FDs as a cache. Just sharing *one* FH is a lot easier. Meanwhile, sharing sigbits is pretty scary stuff. Even with CloseWindowSafely debugged, you can get GURUs pretty easily. And there's no reason to limit SigBits. Ironically, select() on UNIX solves the indeterminate bitmap problem... -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "Really, a video game is nothing more than a Skinner box." -- Peter Merel <pete@basser.oz>
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (12/07/89)
peter@sugar.hackercorp.com (Peter da Silva) writes: > Meanwhile, sharing sigbits is pretty scary stuff. Even with CloseWindowSafely > debugged, you can get GURUs pretty easily. Explain. I share sigbits trivially. Especially just associating a signal with multiple message ports. Signals are like interrupts, and shared in the same way; explain how you can do the same with fd's. (Just the base case; sharing an fd between two files . . . what, you close and reopen all the time?) Signals are actually quite nice. You give the first five signals to your five most common events, and then the rest are probably uncommon enough where they can all share the same signal bit. Multiple signal bits to me are just a convenience . . . -tom
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (12/08/89)
I agree that static limits should be avoided. I agree that principle applies to signal bits. However, sharing signal bits doesn't require any special code in the context I was thinking of. You assign the same bit to several signals because you want to know one of those things happened. It seemed to me your code was a bit more complicated than that. Mainly I was being facetious. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...uunet!pdn!jc3b21!fgd3