Hello,
While using an external C framework (Mac OS X, discrecording OS
framework, FPC 2.4), I noticed that my FPC console app crashes when I
use writeln's in both C threads (callbacks).
Example: Two FPC functions that are called from an external C library
(c_callback1 and c_callback2) -
Okay, than I'll do it by myself.
Thanks for your explanation! If I had a little more time, I would like to
look at the code to improve it, but cause I don't know much about compiler
development this wouldn't be the best idea. I'm faster if I just translate
everything manually.
On Sun, 11 Jul 2010
Basically, any heap memory access and standard pascal I/O are forbidden in
threads started outside FPC, because the necessary thread structures are not
initialized correctly.
Michael.
On Mon, 12 Jul 2010, Alexander Grau wrote:
Hello,
While using an external C framework (Mac OS X, discrecord
Am 12.07.2010 um 13:24 schrieb Michael Van Canneyt:
Basically, any heap memory access and standard pascal I/O are
forbidden in
threads started outside FPC, because the necessary thread structures
are not
initialized correctly.
Is my assumption correct that this means I cannot use much
On Mon, 12 Jul 2010, Alexander Grau wrote:
Am 12.07.2010 um 13:24 schrieb Michael Van Canneyt:
Basically, any heap memory access and standard pascal I/O are forbidden in
threads started outside FPC, because the necessary thread structures are
not
initialized correctly.
Is my assumptio
On 12 Jul 2010, at 13:24, Michael Van Canneyt wrote:
> Basically, any heap memory access and standard pascal I/O are forbidden in
> threads started outside FPC, because the necessary thread structures are not
> initialized correctly.
I think that I've finally found a way to resolve this properly
Am 12.07.2010 um 18:17 schrieb Jonas Maebe:
On 12 Jul 2010, at 13:24, Michael Van Canneyt wrote:
Basically, any heap memory access and standard pascal I/O are
forbidden in
threads started outside FPC, because the necessary thread
structures are not
initialized correctly.
I think that I
Am 12.07.2010 um 18:17 schrieb Jonas Maebe:
On 12 Jul 2010, at 13:24, Michael Van Canneyt wrote:
Basically, any heap memory access and standard pascal I/O are
forbidden in
threads started outside FPC, because the necessary thread
structures are not
initialized correctly.
I think that I
On Mon, 12 Jul 2010, Alexander Grau wrote:
Am 12.07.2010 um 18:17 schrieb Jonas Maebe:
On 12 Jul 2010, at 13:24, Michael Van Canneyt wrote:
Basically, any heap memory access and standard pascal I/O are forbidden in
threads started outside FPC, because the necessary thread structures are
Alexander Grau wrote on Mon, 12 Jul 2010:
Am 12.07.2010 um 18:17 schrieb Jonas Maebe:
On 12 Jul 2010, at 13:24, Michael Van Canneyt wrote:
Basically, any heap memory access and standard pascal I/O are forbidden in
threads started outside FPC, because the necessary thread
structures are not
Michael Van Canneyt wrote on Mon, 12 Jul 2010:
On Mon, 12 Jul 2010, Alexander Grau wrote:
r15557 | jonas | 2010-07-12 18:16:50 +0200 (Mo, 12 Jul 2010) | 3 lines
+ added support for intialising/finalising threads not started via the FPC
runtime
I don't see how this helps, because CRelocateT
Am 12.07.2010 um 22:31 schrieb Jonas Maebe:
Alexander Grau wrote on Mon, 12 Jul 2010:
Am 12.07.2010 um 18:17 schrieb Jonas Maebe:
On 12 Jul 2010, at 13:24, Michael Van Canneyt wrote:
Basically, any heap memory access and standard pascal I/O are
forbidden in
threads started outside FPC, b
Alexander Grau wrote on Mon, 12 Jul 2010:
Am 12.07.2010 um 22:31 schrieb Jonas Maebe:
I forgot to mention: before this works, you have to create at least
one thread using the FPC RTL in order to initialise the threading
subsystem. It can be terminated/freed immediately, see the test
progr
On Mon, 12 Jul 2010, Jonas Maebe wrote:
Alexander Grau wrote on Mon, 12 Jul 2010:
Am 12.07.2010 um 22:31 schrieb Jonas Maebe:
I forgot to mention: before this works, you have to create at least one
thread using the FPC RTL in order to initialise the threading subsystem.
It can be terminat
Michael Van Canneyt wrote on Mon, 12 Jul 2010:
On Mon, 12 Jul 2010, Jonas Maebe wrote:
One small detail : maybe we should create a call 'inittheading' or make the
'IsMultithreaded' variable a property, that, when written, does the
initialization ?
That's a bit cleaner than creating a thread ?
On Mon, 12 Jul 2010, Jonas Maebe wrote:
Michael Van Canneyt wrote on Mon, 12 Jul 2010:
On Mon, 12 Jul 2010, Jonas Maebe wrote:
One small detail : maybe we should create a call 'inittheading' or make the
'IsMultithreaded' variable a property, that, when written, does the
initialization ?
Th
Michael Van Canneyt wrote on Mon, 12 Jul 2010:
On Mon, 12 Jul 2010, Jonas Maebe wrote:
Michael Van Canneyt wrote on Mon, 12 Jul 2010:
One small detail : maybe we should create a call 'inittheading' or make the
'IsMultithreaded' variable a property, that, when written, does the
initialization
Hello, Michael Van Canneyt,
Sorry, I can't write to the resolved issue (without re-opening) it.
> - better class tree (split out binary/unary/primitive operators in subclasses)
> These may break backwards compatiblity; if you prefer to do them yourself, I
> can say what I have in mind.
That's h
18 matches
Mail list logo