| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Multiple threads acca |
PF> > you have the > same issues, but you don't have to use file locking as the > solution. File locking is very mid 80's garbage, and bogs > networks (and servers) down. PF> It depends from how it is used. File locking from multiple workstations all accessing the same file directly is very expensive in terms of LAN traffic, especially if the LAN is resonably robust and able to cope with loss of connection. But the situation that we are discussing shouldn't result in any LAN traffic since all of the contending threads are part of a process running on the server itself, and all file access is local. PF> > Designing a bbs message system (short of using a separate > file for each message) is pretty difficult; there are more > difficult issues to deal with than multi-user access (free > space allocation and reclamation are pretty darn hard!). PF> As I said a couple of messages ago, unlike DOS and FAT, with OS/2 and HPFS it's quite easy to adopt the UNIX philosophy of letting the filesystem handle such things, and go with a one-file-per-message scheme. > JdeBP < ___ X MegaMail 2.10 #0: --- Maximus/2 3.01* Origin: DoNoR/2,Woking UK (44-1483-725167) (2:440/4) SEEN-BY: 50/99 54/99 270/101 620/243 625/160 711/401 413 430 934 712/311 407 SEEN-BY: 712/505 506 517 623 624 704 713/317 800/1 @PATH: 440/4 141/209 270/101 712/624 711/934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.