OA>> I'll think about, but I don't think I'll change from semaphores just yet.
OA>> I don't like the idea of creating temp files for locks, and I can't lock
Actually, cleaning temp file is by far easier than cleaning semaphore.
Especially if your app can be killed any moment.
OA>> against an exi
OA>> I don't think its an option I have for the current
OA>> implementation - it's file IO, and should be much slower, right
OA>> ?
Wrong. Record locking has nothing to do with file I/O - it is done
entirely in memory.
--
[EMAIL PROTECTED] \/ There shall be counsels taken
Stanislav Malysh
gk>> not terribly good portability, according to
gk>> /usr/src/linux/Documentatino/mandatory.txt , for mandatory locks?
gk>> advisory locks can be used, but then you only have a single such lock
gk>> available per file. if you need to use several locks, you need to keep
What? You sure should use
On Sun, 6 May 2001, guy keren wrote:
> > I don't think its an option I have for the current implementation - it's
> > file IO, and should be much slower, right ?
>
> well, i'm not sure that usage of locks performs any file I/O (after all,
> all the locks data is kept in memory, not on disk, as th
> > Yes. This is one of the problems with semaphores. BTW, why not using file
> > locking instead of it? It has much cleaner and richer semantics and almost
> > none of the problems semaphores have.
not terribly good portability, according to
/usr/src/linux/Documentatino/mandatory.txt , for mand
On Sun, 6 May 2001, Oded Arbel wrote:
> I don't know of any other really good Linux programming books out there,
> but if you need something to read to get you started with API programming
> in Linux, or want a backup sitting on your desktop - I can recommend it.
this book sohuld be used not ne
On Thu, 3 May 2001, Itay_Meiri wrote:
> >>Have "Advanced Programming in the UNIX environment" by Richard Stevens -
> >>borring as hell, but serves as a good book holder to prevent my Camel book
> >>from toppeling ;-)
>
> A matter of taste - I've got all his books!
>
True, so true :-)
Don't get m
On 04-May-2001 Stanislav Malyshev a.k.a Frodo wrote:
>>> This is not a PROBLEM but a FEATURE. All Sys-V IPC (semaphores,
>>> message queues, shared memory) outlive their creators.
>
> Wrong. Shared memory can be pre-deleted, so that it is removed when last
> process is detached. Just like files.
>> This is not a PROBLEM but a FEATURE. All Sys-V IPC (semaphores,
>> message queues, shared memory) outlive their creators.
Wrong. Shared memory can be pre-deleted, so that it is removed when last
process is detached. Just like files. Semaphores can not. In fact, there's
no good way to insure th
On 03-May-2001 Stanislav Malyshev a.k.a Frodo wrote:
> OA>> and then leave it lying around and exit the process - will it stay
> OA>> in the system when no current process uses it ?
>
> Yes. This is one of the problems with semaphores. BTW, why not using
This is not a PROBLEM but a FEATURE. All
>
> Hi list.
>
> One more semaphore question if you please - if I create a semaphoer set,
> and then leave it lying around and exit the process - will it stay in the
> system when no current process uses it ?
> If so - what does it take to clear it from the system : loging out ? going
> to runle
OA>> One more semaphore question if you please - if I create a semaphoer set,
OA>> and then leave it lying around and exit the process - will it stay in the
OA>> system when no current process uses it ?
Yes. This is one of the problems with semaphores. BTW, why not using file
locking instead of i
12 matches
Mail list logo
