On 09/12/2013 02:45 PM, Marco van de Voort wrote:
E.g. TComport only starts an helper thread if you register receive
events. If you do not, you can use it in a select/waitformultiple like
way in a thread.
Sounds good.
I'm going to test this ASAP.
-Michael
_
In our previous episode, Michael Schnell said:
> > The very reason I use Synapse is that it DOES NOT use threads.
> > Synapse is simple to use. Keep it so.
>
> Of course I don't vote for Synapse always using threads, but to provide
> _additional_ functions / objects (maybe units) that work simil
On 09/12/2013 02:36 PM, Mark Morgan Lloyd wrote:
Although for certain types of usage being able to get directly to the
hardware (or strictly, to the lowest level the OS supports for normal
users) is absolutely essential, e.g. if timing information has to be
appended to each character or if re
On 09/12/2013 01:28 PM, Michael Van Canneyt wrote:
The very reason I use Synapse is that it DOES NOT use threads.
Synapse is simple to use. Keep it so.
Of course I don't vote for Synapse always using threads, but to provide
_additional_ functions / objects (maybe units) that work similar to
In our previous episode, Mark Morgan Lloyd said:
> > common request, and since the fpc-Team some time ago enabled
> > TThread.Queue in the RTL, this is doable in a straight forward,
> > "fpc-ish" way (portable but Delphi compatible).
>
> Although for certain types of usage being able to get dire
Michael Schnell wrote:
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
I've concluded that using a thread is, in fact, preferable
True.
It's a pity that Synapse and friend (especially SynaSer) does does not
implement internal threads that throw appropriate events in the Main
Thread when s
On Thu, 12 Sep 2013, Michael Schnell wrote:
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
I've concluded that using a thread is, in fact, preferable
True.
It's a pity that Synapse and friend (especially SynaSer) does does not
implement internal threads that throw appropriate events in
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
I've concluded that using a thread is, in fact, preferable
True.
It's a pity that Synapse and friend (especially SynaSer) does does not
implement internal threads that throw appropriate events in the Main
Thread when something comes in (or an
Mark Morgan Lloyd wrote:
Michael Schnell wrote:
On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote:
I'd normally use a thread for this, but I've already got lnet's
telnet client running in the program so would rather stick to the
same library if possible.
AFAIK, Lnet does not do threading int
On Thu, Sep 12, 2013 at 12:01:30PM +0200, Reimar Grabowski wrote:
> On Thu, 12 Sep 2013 07:10:19 +0200 Jürgen Hestermann
> wrote:
>
> > Ahh, that's the reason: It's (another) sloppiness in Unix systems
> > and has creeped into Windows from there.
> Unfortunately M$ hasn't implemented it correctly
On Thu, 12 Sep 2013 07:10:19 +0200
Jürgen Hestermann wrote:
> Ahh, that's the reason:
> It's (another) sloppiness in Unix systems and has creeped into Windows from
> there.
Unfortunately M$ hasn't implemented it correctly (like always) and enriched the
experience with their common inconsistenci
Mark Morgan Lloyd wrote:
Is it feasible to use lnet for a simple TCP daemon on Linux, i.e. wait
for a connection on a predefined port, read as much data as is
available, repeat? And if so, what does the SerSock parameter to
Accept() represent?
I'd normally use a thread for this, but I've al
Michael Schnell wrote:
On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote:
I'd normally use a thread for this, but I've already got lnet's telnet
client running in the program so would rather stick to the same
library if possible.
AFAIK, Lnet does not do threading internally (as does AsyncPro
On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote:
I'd normally use a thread for this, but I've already got lnet's telnet
client running in the program so would rather stick to the same
library if possible.
AFAIK, Lnet does not do threading internally (as does AsyncPro or -
partly - Indy), so
14 matches
Mail list logo
