I've got a class factory problem I'm trying to resolve and it appears
I'm at a point where it's probably better to ask for help.
TCoreObjects=class;
TCoreObject=Class (TPersistent)
protected
class procedure VerifyIDs(var Module:TDBMSModule); Virtual; abstract;
end;
TAdminCore=Class(T
On Sat, Oct 16, 2010 at 2:16 PM, Michael Van Canneyt
wrote:
> It would allow me to write programs that are multithreaded and don't use
> external libs.
Right. Every interface between the kernel space and user space add at
least one degree of inefficiency. So every FPC program would be
carrying
On Sat, Oct 16, 2010 at 2:16 PM, Henry Vermaak wrote:
> libpthread.so is the name of the library, not the name of the implementation.
I updated FPC from SVN and it is pointing to this library now :-).
Only problem is someone took some changes I made to remove semaphore
on thread creation... If I
On 16 October 2010 14:37, Andrew Brunner wrote:
> On Fri, Oct 15, 2010 at 5:10 PM, Henry Vermaak
> wrote:
>> pthreads is the standard, not the implementation. The current most
>> widely used implementation is called NPTL. Your link points to
>> LinuxThreads (judging by the name, I didn't downl
On Sat, 16 Oct 2010, Marco van de Voort wrote:
All I have seen is some complaint about slow starting threads by sb who can't
even find the proper pthread source, and now we are suddenly making room for
a native threadmanager?
Isn't a native threadmanager for Linux on the wishlist of FPC user
On 16.10.2010 18:30, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
First we would have to get rid of "this solution in search of a problem"
attitude.
What do you mean by the "this solution in search of a problem" attitude?
I can't follow you currently... :(
People seem
In our previous episode, Sven Barth said:
> >>> First we would have to get rid of "this solution in search of a problem"
> >>> attitude.
> >>
> >> What do you mean by the "this solution in search of a problem" attitude?
> >> I can't follow you currently... :(
> >
> > People seem to first want to b
On Sat, 16 Oct 2010 18:04:59 +0200, Luca Olivetti wrote:
I use that only for threads I start at the beginning of the app and
terminate at the end, so polling isn't a big issue.
Those kind of threads are not a big issue at all. As they are running
during the whole application's lifetime, race
Jonas Maebe wrote:
>> As written before it does not crash in
>> tmsethread which does not inherit from FPC TThread.
>
> You're just getting lucky in your tests.
>
Hmm, a miracle for me. I used heaptrace which trashes the memory after free
AFAIK?
Martin
__
Al 16/10/10 17:49, En/na Vinzent Höfler ha escrit:
On Sat, 16 Oct 2010 17:42:03 +0200, Luca Olivetti wrote:
Al 16/10/10 16:57, En/na Vinzent Höfler ha escrit:
Well, the usual implementation of an externally called "Destroy" is
- first a call to the Terminate method
- then a WaitFor()
Nop
Al 16/10/10 17:42, En/na Luca Olivetti ha escrit:
Al 16/10/10 16:57, En/na Vinzent Höfler ha escrit:
Well, the usual implementation of an externally called "Destroy" is
- first a call to the Terminate method
- then a WaitFor()
Nope, I avoid the WaitFor. I usually do a
while not FFinished d
On Sat, 16 Oct 2010 17:42:03 +0200, Luca Olivetti wrote:
Al 16/10/10 16:57, En/na Vinzent Höfler ha escrit:
Well, the usual implementation of an externally called "Destroy" is
- first a call to the Terminate method
- then a WaitFor()
Nope, I avoid the WaitFor.
Nice for you, but I'd rath
On 16 Oct 2010, at 14:23, "Uffe Kousgaard" wrote:
> "Sven Barth" wrote in
> message
>>
>> TCriticalSection is a WinAPI struct if you include the unit Windows.
Appart from unit ordering (which is a shaky way of reliably resolving things),
you could always qualify the name with the unit prefix
On Sat, 16 Oct 2010 17:12:51 +0200, Jonas Maebe
wrote:
On 16 Oct 2010, at 17:13, Martin Schreiber wrote:
As written before it does not crash in
tmsethread which does not inherit from FPC TThread.
You're just getting lucky in your tests.
Either that, or the object validity checks are off
Al 16/10/10 16:57, En/na Vinzent Höfler ha escrit:
Well, the usual implementation of an externally called "Destroy" is
- first a call to the Terminate method
- then a WaitFor()
Nope, I avoid the WaitFor. I usually do a
while not FFinished do
CheckSynchronize(100);
(where FFinished is
On 16.10.2010 16:47, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
FreeBSD supports rfork, which has similar functionality (the subset (?)
implemented by "Clone" in the linuxator is implemented by a rfork call
Yrying to build on the clone call has been done in 1.0.x times,
On 16 Oct 2010, at 17:13, Martin Schreiber wrote:
> Jonas Maebe wrote:
>
>> The contents of AfterConstruction don't matter. If the instance is freed
>> before the constructor had a chance to call AfterConstruction, the self
>> pointer won't be valid anymore in the constructor and hence the call
Jonas Maebe wrote:
>
> On 16 Oct 2010, at 15:46, Martin Schreiber wrote:
>
>>
>> Will it crash if it is empty as in TObject?
>
> The contents of AfterConstruction don't matter. If the instance is freed
> before the constructor had a chance to call AfterConstruction, the self
> pointer won't be
On Sat, 16 Oct 2010 10:45:49 +0200, Luca Olivetti wrote:
Al 15/10/10 22:31, En/na Vinzent Höfler ha escrit:
- FreeOnTerminate should be gone, (meaning no way to actively call
TThread.Destroy from another thread, a thread gets destroyed
automatically when it leaves its execute method)
I don'
In our previous episode, Sven Barth said:
> > FreeBSD supports rfork, which has similar functionality (the subset (?)
> > implemented by "Clone" in the linuxator is implemented by a rfork call
> >
> > Yrying to build on the clone call has been done in 1.0.x times, and I don't
> > have fond memories
On 16.10.2010 15:45, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
How about creating
a) A native TThreadManager record in system unit for unices.
I don't think this can be done for all Unix systems in a generic way,
because e.g. on Linux you should use the "clone" sysca
On 16 Oct 2010, at 15:46, Martin Schreiber wrote:
> Jonas Maebe wrote:
>
>> He cannot. If freeonterminate=true, then even if you call "inherited
>> create(false)" as the very last statement of your constructor, the thread
>> may already have finished running and freed itself before
>> AfterConst
In our previous episode, Sven Barth said:
> > How about creating
> >
> > a) A native TThreadManager record in system unit for unices.
>
> I don't think this can be done for all Unix systems in a generic way,
> because e.g. on Linux you should use the "clone" syscall (which is Linux
> only)
Free
Jonas Maebe wrote:
>
> He cannot. If freeonterminate=true, then even if you call "inherited
> create(false)" as the very last statement of your constructor, the thread
> may already have finished running and freed itself before
> AfterConstruction is called. The AfterConstruction call will then c
In our previous episode, Michael Van Canneyt said:
> >
> > IMO, it would be better to leverage the present performance condition
> > to muster support for a high performance thread component set.
>
> How about creating
>
> a) A native TThreadManager record in system unit for unices.
>
> b) Creat
On 16.10.2010 15:36, Michael Van Canneyt wrote:
How about creating
a) A native TThreadManager record in system unit for unices.
I don't think this can be done for all Unix systems in a generic way,
because e.g. on Linux you should use the "clone" syscall (which is Linux
only) while on e.g.
On Fri, Oct 15, 2010 at 5:10 PM, Henry Vermaak wrote:
> I've told you before: NPTL is part of the glibc sources. Download the
> latest glibc sources and look in the nptl directory. The latest glibc
> release is 2.11.2.
FPC source to cThreads unit and the thread manager associated with
threadin
On Sat, 16 Oct 2010, Andrew Brunner wrote:
On Sat, Oct 16, 2010 at 7:04 AM, Jonas Maebe wrote:
He cannot. If freeonterminate=true, then even if you call "inherited
create(false)" as the very last statement of your constructor, the thread
may already have finished running and freed itself be
On Sat, Oct 16, 2010 at 7:04 AM, Jonas Maebe wrote:
> He cannot. If freeonterminate=true, then even if you call "inherited
> create(false)" as the very last statement of your constructor, the thread
> may already have finished running and freed itself before AfterConstruction
> is called. The Aft
"Sven Barth" wrote in
message
>
> TCriticalSection is a WinAPI struct if you include the unit Windows.
OK, that explains. In Delphi the WinAPI struct is called
TRTLCriticalSection. So, no name clashing.
___
fpc-pascal maillist - fpc-pascal@lists.
Hi together!
I'm currently wrapping V4L2 in an object oriented way and thought that I
could use operator overloading to convert flag ordinals to Pascal sets.
My operator compiled without problems, but when I tried to use it I got
a type error.
So I reduced my problem to a single test unit:
On 16 Oct 2010, at 13:57, Benedikt Schindler wrote:
>>> - FreeOnTerminate should be gone, (meaning no way to actively call
>>> TThread.Destroy from another thread, a thread gets destroyed
>>> automatically when it leaves its execute method)
>>> (IIRC FreeOnTerminate was even set to False by the d
>
>> - FreeOnTerminate should be gone, (meaning no way to actively call
>> TThread.Destroy from another thread, a thread gets destroyed
>> automatically when it leaves its execute method)
>> (IIRC FreeOnTerminate was even set to False by the default
>> constructor, so you had the choice of e
On 16.10.2010 12:35, Uffe Kousgaard wrote:
"Jonas Maebe" wrote in
message news:6ef537cb-d266-4034-8c96-8286158ac...@elis.ugent.be...
1) Whenever I compile "single = min(single,single)" I have to add math.min
or the win32 compiler complains and expects longints instead. Is there a
difference be
"Jonas Maebe" wrote in
message news:6ef537cb-d266-4034-8c96-8286158ac...@elis.ugent.be...
> 1) Whenever I compile "single = min(single,single)" I have to add math.min
> or the win32 compiler complains and expects longints instead. Is there a
> difference between the RTL in the two versions?
> C
On 16 Oct 2010, at 12:11, Uffe Kousgaard wrote:
> I am still compiling delphi code and do now compile for both win32 and
> winCE. WinCE works (but executable untested), while win32 complains a few
> places:
>
> 1) Whenever I compile "single = min(single,single)" I have to add math.min
> or th
I am still compiling delphi code and do now compile for both win32 and
winCE. WinCE works (but executable untested), while win32 complains a few
places:
1) Whenever I compile "single = min(single,single)" I have to add math.min
or the win32 compiler complains and expects longints instead. Is th
On Sat, 16 Oct 2010, Luca Olivetti wrote:
Al 15/10/10 22:31, En/na Vinzent Höfler ha escrit:
- FreeOnTerminate should be gone, (meaning no way to actively call
TThread.Destroy from another thread, a thread gets destroyed
automatically when it leaves its execute method)
I don't agree, the c
Al 15/10/10 22:31, En/na Vinzent Höfler ha escrit:
- FreeOnTerminate should be gone, (meaning no way to actively call
TThread.Destroy from another thread, a thread gets destroyed
automatically when it leaves its execute method)
I don't agree, the creator of the thread should be able to see wha
39 matches
Mail list logo
