[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpm-devel
Subject:    Re: typo in os_handle.c for qnx
From:       Peter Kalbus <peter.kalbus () gmx ! de>
Date:       2008-01-24 21:15:00
Message-ID: 7391A1A2-1DFA-4405-AF61-BFDCE1C6ACA2 () gmx ! de
[Download RAW message or body]

great, if you have a solution for that point.

currently, i think, this is the biggest issue.

-piet


Am 24.01.2008 um 21:20 schrieb Jeff Johnson:

>
> On Jan 24, 2008, at 3:11 PM, Peter Kalbus wrote:
>
>> i got the following information from the oracle guyes:
>>
>> <......>
>> Content of the new Post:
>>>> is may underatanding is correct, that multiple applications may  
>>>> access the >>same databases (perhaps not at the same time, but  
>>>> that could be >>serialized/blocked), but not a single application  
>>>> have a single database opened >>twice?
>> Yes, you are right: normally multiple threads of control (ie,  
>> processes and /or threads) can access the same database environment  
>> and the databases concurrently when you make the right  
>> configuration, internal synchronization can make different  
>> transactions isolated, the ACID properties of transaction can be  
>> guaranteed.
>>
>> But in the QNX port of Berkeley db4.6.21, there is a bug about  
>> mmaped files, causing the regions unable to be created using mmap,  
>> so you have to use DB_PRIVATE and access the environment in the  
>> same process. This is an workaround for now.
>>
>>>> i understand, that you cannot give a date of release for the qnx  
>>>> support. will it >>be part of 4.7 or 5.0?
>> the bug above described on QNX will be fixed in 4.7 release, so in  
>> 4.7 release, you will be able to make use of all functionalities of  
>> Berkeley db on QNX.
>> <......>
>>
>> i don't know what DB_PRIVATE means. is it possible to use the  
>> mentioned configuration for the qnx version of rpm5? if so, what  
>> will be the drawbacks? since it's you a matter of time, when db 4.7  
>> will be released, that could be a far better solution, than  
>> publishing someting that makes problems.
>>
>
> So mmap, not pthread locking.
>
> DB_PRIVATE disables locking through a dbenv.
>
> That means that QNX will need to use a global shared/exclusive
> fcntl lock.
>
> Lemme fiddle up a patch for QNX. I'll post soonishly.
>
> 73 de Jeff
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org

______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org
[prev in list] [next in list] [prev in thread] [next in thread]