RE: [fpc-devel] syncobjs unit
The thing is full of this. Problem is, each OS and platform has slightly different arguments and return types AND we need to be flexible enough to support more than one threading implementation on same platform too (so no godamn ifdefs). use INT64 everywhere? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
On Sun, 26 Nov 2006, C Western wrote: Does the syncobjs unit in the FCL need to be machine dependent any more? The functionality seems to be in the thread manager for all the platforms that have threads, and I had some problems using the unit. (TRTLCriticalSection is defined in sybcobjs and as part of the system thread stuff). The attached patch shows what I had in mind - delete all the syncobjs.pp files in the platform directories. Does the patch work for you ? If so, I'll apply it to FCL. It was planned to do something similar, since when syncobjs was implemented, the TThreadManager did not yet exist. Now that it does exist, syncobjs can be implemented on top of it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
Does the patch work for you ? If so, I'll apply it to FCL. It was planned to do something similar, since when syncobjs was implemented, the TThreadManager did not yet exist. Now that it does exist, syncobjs can be implemented on top of it. It might be perhaps better to wait until the whole ThreadManager problem is solved one way or the other. No matter which solution is chosen it's API is going to change. No idea when someone's going to step up to it tho. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
It might be perhaps better to wait until the whole ThreadManager problem is solved one way or the other. What exactly is the ThreadManager problem ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
What exactly is the ThreadManager problem ? There are type differences in return types and arguments of many functions. For example, ThreadManager.SuspendThread returns DWord in all OSes and platforms (64bit 32bit) but eg: in cthreads we use: Result := pthread_kill().. pthread_kill returns an int. The thing is full of this. Problem is, each OS and platform has slightly different arguments and return types AND we need to be flexible enough to support more than one threading implementation on same platform too (so no godamn ifdefs). If you got a nice idea come up with it coz I'm kind of lost. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
If you got a nice idea come up with it coz I'm kind of lost. First thing that comes into my mind: Use a TP-specific propriety integer value as a result and store the OS specific value in an OS specific property so that it can be checked if the user really needs to. The OS specific property might be - an OS specific type - just some thing big enough (int64) so that it can be typecasted as necessary or - there could by multiple of those properties with different types Is this silly ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
One solution is basicly to use a TThreadID kind of thing for all arguments and return types. The problems with this are: 1. if one OS has multiple threading backends with multiple types, what then? (ifdef isn't enough here) 2. who is going to check all platforms all usages of ThreadManager and fix them? Who is going to test this. Another solution is to use one big-enough type. But one day big-enough isn't going to be big enough and it still has problem #2. In any case it's going to hurt. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
Aleš Katona schrieb: One solution is basicly to use a TThreadID kind of thing for all arguments and return types. The problems with this are: 1. if one OS has multiple threading backends with multiple types, what then? (ifdef isn't enough here) 2. who is going to check all platforms all usages of ThreadManager and fix them? Who is going to test this. People will cry if things break, that's how OSS works. Another solution is to use one big-enough type. But one day big-enough isn't going to be big enough and it still has problem #2. It can be increased, but 128 bit is at least (128-64) bit/0.5 bit/year away :) Example: the transition from 32 bit to 64 bit filepos and size wasn't even noticed by anybody :) In any case it's going to hurt. Well, it sounds complicated but usually it isn't that bad. If TThreadID isn't enough, indroduce a new type like TThreadKillResult. For multiple thread manager on the same target use the biggest type approach. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
On 27 nov 2006, at 13:56, Florian Klaempfl wrote: Another solution is to use one big-enough type. But one day big- enough isn't going to be big enough and it still has problem #2. It can be increased, but 128 bit is at least (128-64) bit/0.5 bit/ year away :) I really think this does not matter in any way. Afaik the routines which are affected all only return error codes, not values. So what is really needed is a set of FPC-defined error codes, and translations from the OS-specific error codes to these FPC error codes. Whether these FPC error codes are signed or not doesn't matter, and by the time people need more than 2**32 individual error code conditions regarding why a mutex (un)lock failed they'll need automatic ways to deal with that anyway. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
On 27 nov 2006, at 13:56, Florian Klaempfl wrote: Another solution is to use one big-enough type. But one day big- enough isn't going to be big enough and it still has problem #2. It can be increased, but 128 bit is at least (128-64) bit/0.5 bit/ year away :) I really think this does not matter in any way. Afaik the routines which are affected all only return error codes, not values. So what is really needed is a set of FPC-defined error codes, and translations from the OS-specific error codes to these FPC error codes. Whether these FPC error codes are signed or not doesn't matter, and by the time people need more than 2**32 individual error code conditions regarding why a mutex (un)lock failed they'll need automatic ways to deal with that anyway. I also think this is the right way. If you specify OS specific return codes per threadmanager, this will lead to unnecssary breakage. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
I also think this is the right way. If you specify OS specific return codes per threadmanager, this will lead to unnecssary breakage. Return codes are one thing, argument another. What are we going to do about those? Eg: see ExitCode argument. It's a dword but int is expected as well. These can't be internaly abstracted like error codes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
On 27 nov 2006, at 15:18, Aleš Katona wrote: I also think this is the right way. If you specify OS specific return codes per threadmanager, this will lead to unnecssary breakage. Return codes are one thing, argument another. What are we going to do about those? Eg: see ExitCode argument. It's a dword but int is expected as well. These can't be internaly abstracted like error codes. I'd use a pointer, ptrint or ptruint in those cases. They naturally grow with the cpu bitsize. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
I'd use a pointer, ptrint or ptruint in those cases. They naturally grow with the cpu bitsize. Sure and when it's a size_t expected? Perhaps we should use unions.. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
On Mon, 27 Nov 2006, Aleš Katona wrote: I also think this is the right way. If you specify OS specific return codes per threadmanager, this will lead to unnecssary breakage. Return codes are one thing, argument another. What are we going to do about those? Eg: see ExitCode argument. It's a dword but int is expected as well. These can't be internaly abstracted like error codes. Take the lowest common denominator. I think you're seeking too much problems. Just implement an interface that is workable on all OS-es, and can be used to implement TThread and syncobjs. We don't need the full-blown Win32 API for threads, nor do we need the complete pthreads. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
I'd use a pointer, ptrint or ptruint in those cases. They naturally grow with the cpu bitsize. Sure and when it's a size_t expected? Perhaps we should use unions.. I wouldn't try to cater to each eventuality and possible problem. Just make sure the main problems are covered. Better make a few exceptions/hacks here and there, then have a system that requires a 4 weeks course to handle. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] syncobjs unit
I can't find any such functions in unix/cthreads.pp (nor in the system-dependent pthread include files), nor in win/systhrd.inc Who knows, perhaps syllable has such :) Point was, I think we should try to make threading more future proof this time. I'll try to make a list of required arguments and return types between platforms. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] syncobjs unit
Does the syncobjs unit in the FCL need to be machine dependent any more?
The functionality seems to be in the thread manager for all the
platforms that have threads, and I had some problems using the unit.
(TRTLCriticalSection is defined in sybcobjs and as part of the system
thread stuff). The attached patch shows what I had in mind - delete all
the syncobjs.pp files in the platform directories.
Colin
diff -uNr --exclude=.svn --exclude=fpc.spec trunk/fpcsrc/fcl/inc/syncobh.inc trunk.w/fpcsrc/fcl/inc/syncobh.inc
--- trunk/fpcsrc/fcl/inc/syncobh.inc 2005-10-04 20:57:24.0 +0100
+++ trunk.w/fpcsrc/fcl/inc/syncobh.inc 2006-11-25 13:54:24.0 +
@@ -44,9 +44,7 @@
TEventObject = class(THandleObject)
private
- FSem: Pointer;
FManualReset: Boolean;
- FEventSection: TCriticalSection;
public
constructor Create(EventAttributes : PSecurityAttributes;
AManualReset,InitialState : Boolean;const Name : string);
diff -uNr --exclude=.svn --exclude=fpc.spec trunk/fpcsrc/fcl/inc/syncobjs.pp trunk.w/fpcsrc/fcl/inc/syncobjs.pp
--- trunk/fpcsrc/fcl/inc/syncobjs.pp 1970-01-01 01:00:00.0 +0100
+++ trunk.w/fpcsrc/fcl/inc/syncobjs.pp 2006-11-25 13:59:05.0 +
@@ -0,0 +1,113 @@
+{
+This file is part of the Free Component Library (FCL)
+Copyright (c) 1998 by Florian Klaempfl
+member of the Free Pascal development team
+
+See the file COPYING.FPC, included in this distribution,
+for details about the copyright.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+ **}
+{$mode objfpc}
+{$h+}
+unit syncobjs;
+
+interface
+
+uses
+ sysutils;
+
+type
+ PSecurityAttributes = Pointer;
+ TEventHandle = Pointer;
+ // TRTLCriticalSection = TPthreadMutex;
+
+const
+ INFINITE = Cardinal(-1);
+
+{$I syncobh.inc}
+
+implementation
+
+{ -
+Real syncobjs implementation
+ -}
+
+{$I syncob.inc}
+
+
+procedure TCriticalSection.Acquire;
+
+begin
+ EnterCriticalSection(CriticalSection);
+end;
+
+procedure TCriticalSection.Release;
+
+begin
+ LeaveCriticalSection(CriticalSection);
+end;
+
+constructor TCriticalSection.Create;
+
+begin
+ Inherited Create;
+ InitCriticalSection(CriticalSection);
+end;
+
+destructor TCriticalSection.Destroy;
+
+begin
+ DoneCriticalSection(CriticalSection);
+end;
+
+destructor THandleObject.destroy;
+
+begin
+end;
+
+constructor TEventObject.Create(EventAttributes : PSecurityAttributes;
+ AManualReset,InitialState : Boolean;const Name : string);
+
+begin
+ FHandle := BasicEventCreate(EventAttributes, AManualReset, InitialState, Name);
+ FManualReset:=AManualReset;
+end;
+
+destructor TEventObject.destroy;
+
+begin
+ BasicEventDestroy(Handle);
+end;
+
+procedure TEventObject.ResetEvent;
+
+begin
+ BasicEventResetEvent(Handle);
+end;
+
+procedure TEventObject.SetEvent;
+
+begin
+ BasicEventSetEvent(Handle);
+end;
+
+
+function TEventObject.WaitFor(Timeout : Cardinal) : TWaitResult;
+
+begin
+ Result := TWaitResult(basiceventWaitFor(Timeout, Handle));
+ if Result = wrError then
+FLastError := GetLastOSError;
+end;
+
+constructor TSimpleEvent.Create;
+
+begin
+ inherited Create(nil, True, False, '');
+end;
+
+end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
