Vinzent Höfler wrote:
> because we assume it's non-recursive, that was the whole point. So we
> should *first* check the count and then may lock/unlock the mutex
> accordingly.
Note that these two actions must be atomic. This is what the TryLock is for.
Micha
_
I have a problem compiling the compiler. After a lot of compilation it
attempts to compile pp.pas and I get the following error:
pp.pas(213,1) Error: Entrypoint start not defined.
Regards,
Andreas
___
fpc-pascal maillist - fpc-pascal@lists.freepa
Am Montag, 24. Juli 2006 23:38 schrieb Vinzent Höfler:
> Vinzent Höfler wrote:
> > Hmm. So we'd need a mutex inside a mutex. Now I know why they call
> > it recursive. ;) So it'll be something like that:
> >
> > function Recursive_Mutex.Lock : ...;
> > begin
> >// Lock mutex inside mutex.
> >
Vinzent Höfler wrote:
Hmm. So we'd need a mutex inside a mutex. Now I know why they call it
recursive. ;) So it'll be something like that:
function Recursive_Mutex.Lock : ...;
begin
// Lock mutex inside mutex.
self.Owner_Check_Lock.Lock;
// Owned by current thread?
if CurrentThrea
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 22:05 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 20:33 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
[..]
btw. this is not TEvent, we are talking about, it's rtlevent ..
TEvent (in synconjs) is implemented
Am Montag, 24. Juli 2006 22:05 schrieb Vinzent Höfler:
> Burkhard Carstens wrote:
> > Am Montag, 24. Juli 2006 20:33 schrieb Vinzent Höfler:
> >> Burkhard Carstens wrote:
> >>> [..]
> >>>
> ... As long as rtlevent is used with this
> in mind, it should give a consistent behaviour on windo
I'm new to free-pascal, and have searched for a few hours without
finding an answer to my question. I hope someone on the list could
please help point me in the right direction.
I've been using a couple of encryption/decryption units that are written
in Pascal that I've been using in a usersp
Micha Nelissen wrote:
Vinzent Höfler wrote:
Currently all I see is a subtle semantic difference between Windows- and
Unix-Event's implementation.
AFAICS, it's as close as it can get. You mean subtle as in, unimportant,
or as in, possibly fatal ? :-) If possibly fatal, describe when/how.
If u
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 20:33 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
[..]
... As long as rtlevent is used with this
in mind, it should give a consistent behaviour on windows and
linux.
"this in mind" means: The only way how rtlevent should be used is:
1. c
Am Montag, 24. Juli 2006 20:33 schrieb Vinzent Höfler:
> Burkhard Carstens wrote:
> > Am Montag, 24. Juli 2006 19:22 schrieb Vinzent Höfler:
> >> Burkhard Carstens wrote:
> >>> Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler:
> > - the rtlEvent works even with timeout (with my patch post
Michael Van Canneyt wrote:
>
> 2.1.x because 2.0.4 is the last 2.0 release.
All new development is done in trunk or a branch of trunk. If things
prove that they are working, they are merged to fixes.
___
fpc-pascal maillist - fpc-pascal@lists.freepas
On Mon, 24 Jul 2006, Andreas Berger wrote:
>
>
> > BTW a new release 2.0.4, with a load of bug fixes, updates, is being
> > prepared for release within next weeks - we are currently on rc2.
> >
> Thanks for the clear instructions. This should really be in the FAQ or Wiki.
>
> Just a few q
Lee, John wrote:
Suggest you read these links - but from memory this is what you do. As was said before the utils are not included in snapshots- usually it's just the minimum there.
A) you need to download the latest go32v2 release which is 2.0.2 eg from ftpmaster.freepascal.org or another ftp
Vinzent Höfler wrote:
> Currently all I see is a subtle semantic difference between Windows- and
> Unix-Event's implementation.
AFAICS, it's as close as it can get. You mean subtle as in, unimportant,
or as in, possibly fatal ? :-) If possibly fatal, describe when/how.
> So for now all I can say
Am Montag, 24. Juli 2006 20:33 schrieb Vinzent Höfler:
> Burkhard Carstens wrote:
> > [..]
> >
> >> ... As long as rtlevent is used with this
> >> in mind, it should give a consistent behaviour on windows and
> >> linux.
> >
> > "this in mind" means: The only way how rtlevent should be used is:
> >
Florian Klaempfl wrote:
I didn't understand and follow the whole thread but please submit a bug
report if something in FPC needs to be fixed :)
Well, I'll do as soon as I'm sure if there's a bug. :)
Currently all I see is a subtle semantic difference between Windows- and
Unix-Event's impleme
Vinzent Höfler wrote:
I didn't understand and follow the whole thread but please submit a bug
report if something in FPC needs to be fixed :)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pas
Burkhard Carstens wrote:
[..]
... As long as rtlevent is used with this
in mind, it should give a consistent behaviour on windows and linux.
"this in mind" means: The only way how rtlevent should be used is:
1. call rtlstartwait
2. start the code (e.g. start/resume a thread), that signals the
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 19:22 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler:
- the rtlEvent works even with timeout (with my patch posted on
mantis), but this one clears the signaled state, when wait is
called.
[..]
> ... As long as rtlevent is used with this
> in mind, it should give a consistent behaviour on windows and linux.
"this in mind" means: The only way how rtlevent should be used is:
1. call rtlstartwait
2. start the code (e.g. start/resume a thread), that signals the event.
3. call rtlwaiteve
Am Montag, 24. Juli 2006 19:22 schrieb Vinzent Höfler:
> Burkhard Carstens wrote:
> > Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler:
> >>> - the rtlEvent works even with timeout (with my patch posted on
> >>> mantis), but this one clears the signaled state, when wait is
> >>> called.
> >>
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler:
- the rtlEvent works even with timeout (with my patch posted on
mantis), but this one clears the signaled state, when wait is
called.
>>
*oh* Before the wait? That's not good. This cries for race conditions
and s
Suggest you read these links - but from memory this is what you do. As was said
before the utils are not included in snapshots- usually it's just the minimum
there.
A) you need to download the latest go32v2 release which is 2.0.2 eg from
ftpmaster.freepascal.org or another ftp site, from
/pub
> Steve Williams wrote:
> > Andreas Berger wrote:
> >> I downloaded the latest snapshot and wish to recompile the fpc
> >> compiler for G032v2. I found an old doc that says to:
> >> cd compiler
> >> make cycle
> >>
> >> This obviously will not work since FPC has fpcmake and not make.
> >> The
Steve Williams wrote:
Andreas Berger wrote:
I downloaded the latest snapshot and wish to recompile the fpc
compiler for G032v2. I found an old doc that says to:
cd compiler
make cycle
This obviously will not work since FPC has fpcmake and not make.
There is also no makefile called cycle
Andreas Berger wrote:
I downloaded the latest snapshot and wish to recompile the fpc compiler
for G032v2. I found an old doc that says to:
cd compiler
make cycle
This obviously will not work since FPC has fpcmake and not make. There
is also no makefile called cycle in the compiler folder.
Am Montag, 24. Juli 2006 17:42 schrieb Andreas Berger:
> I downloaded the latest snapshot and wish to recompile the fpc
> compiler for G032v2. I found an old doc that says to:
> cd compiler
> make cycle
>
> This obviously will not work since FPC has fpcmake and not make.
> There is also no make
I downloaded the latest snapshot and wish to recompile the fpc compiler
for G032v2. I found an old doc that says to:
cd compiler
make cycle
This obviously will not work since FPC has fpcmake and not make. There
is also no makefile called cycle in the compiler folder. Can someone
tell me how
Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler:
> On Monday 24 July 2006 14:57, Burkhard Carstens wrote:
> > I vote for more pascal based versions of TMutex, TSemaphore and
> > TEvent, that behaves just like the ones in Delphi and use the
> > system specific functions (like pthread stuff) o
On Monday 24 July 2006 14:57, Burkhard Carstens wrote:
> I vote for more pascal based versions of TMutex, TSemaphore and
> TEvent, that behaves just like the ones in Delphi and use the system
> specific functions (like pthread stuff) only internally in their
> simplest/most portable form.
I'd vot
Am Montag, 24. Juli 2006 16:19 schrieb Vinzent Hoefler:
> On Monday 24 July 2006 14:09, Michael Van Canneyt wrote:
> > On Mon, 24 Jul 2006, Vinzent Hoefler wrote:
> > > On Monday 24 July 2006 13:34, Marco van de Voort wrote:
> > >>> When I run the Unit Tests and create a single Lock and the
> > >>>
Looking at unit syncobjs might save you some ifdefs and trouble.
Thanks for the tip. I always get hassled about keeping the IFDEF's as
little as possible. I will go browse the SyncObjs unit now.
Regards,
Graeme.
--
There's no place like 127.0.0.1
___
Hi Vinzent,
You got me one the right track, I think... :-)
I thought the counter in Semaphores get incremented, but as you stated
(and reading some Man Pages), they get decremented.
I then change my code from:
> if sem_init(FSemaphore, 0, 1) <> 0 then
> raise Exception.Create('Failed to
On Monday 24 July 2006 14:09, Michael Van Canneyt wrote:
> On Mon, 24 Jul 2006, Vinzent Hoefler wrote:
> > On Monday 24 July 2006 13:34, Marco van de Voort wrote:
> >>> When I run the Unit Tests and create a single Lock and the Unlock
> >>> it, all works fine. If I then iterrate that test by creat
On Mon, 24 Jul 2006, Vinzent Hoefler wrote:
On Monday 24 July 2006 13:34, Marco van de Voort wrote:
When I run the Unit Tests and create a single Lock and the Unlock
it, all works fine. If I then iterrate that test by creating 10
locks and then call unlock 10 times, the Unit Tests freeze on
On Monday 24 July 2006 13:34, Marco van de Voort wrote:
> > When I run the Unit Tests and create a single Lock and the Unlock
> > it, all works fine. If I then iterrate that test by creating 10
> > locks and then call unlock 10 times, the Unit Tests freeze on the
> > following line with the second
On Monday 24 July 2006 10:21, Graeme Geldenhuys wrote:
> procedure TtiPool.CreatePoolSemaphore;
> begin
> {$IFDEF MSWINDOWS}
> if FSemaphore <> 0 then
> CloseHandle( FSemaphore ) ;
> FSemaphore := CreateSemaphore( nil, FiMaxPoolSize, FiMaxPoolSize,
> nil ); {$ENDIF MSWINDOWS}
> {$IFDEF
> Looking at my code, I might have initialized my semaphore incorrectly.
>
> The Windows portion works, and I tried to port it to Linux as follows...
>
> procedure TtiPool.CreatePoolSemaphore;
> begin
> {$IFDEF MSWINDOWS}
> if FSemaphore <> 0 then
> CloseHandle( FSemaphore ) ;
> FSemaph
> When I run the Unit Tests and create a single Lock and the Unlock it,
> all works fine. If I then iterrate that test by creating 10 locks and
> then call unlock 10 times, the Unit Tests freeze on the following line
> with the second iteration:
Sounds like some recursion property is not set.
>
Looking at my code, I might have initialized my semaphore incorrectly.
The Windows portion works, and I tried to port it to Linux as follows...
procedure TtiPool.CreatePoolSemaphore;
begin
{$IFDEF MSWINDOWS}
if FSemaphore <> 0 then
CloseHandle( FSemaphore ) ;
FSemaphore := CreateSemaphore(
Hi,
I am having troubles with porting Semaphores in a project under Linux.
Under Windows everything works fine, but under Linux my app keeps
freezing.
The project is tiOPF v2 (TechInsite Object Persistent Framework).
There is a class called TtiPool, that handles a pool of database
connections.
Tomas Hajny wrote:
> In any case, you might try compilation of sources exported from SVN tag
> release_2_0_4_rc2 - starting with "make compiler_cycle" in fpcsrc
> directory and then possibly continuing with release-like build. I guess
> that this could be done using the makepack script, but I'm no
42 matches
Mail list logo
