Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.sys.apple2.programmer > #3429 > unrolled thread

Calling Marinetti from an init

Started byStephen Heumann <stephen.heumann@gmail.com>
First post2017-04-20 22:53 -0500
Last post2017-05-02 21:13 -0500
Articles 4 — 2 participants

Back to article view | Back to comp.sys.apple2.programmer


Contents

  Calling Marinetti from an init Stephen Heumann <stephen.heumann@gmail.com> - 2017-04-20 22:53 -0500
    Re: Calling Marinetti from an init andrew.roughan@writeme.com - 2017-05-02 16:58 -0700
      Re: Calling Marinetti from an init andrew.roughan@writeme.com - 2017-05-02 17:03 -0700
      Re: Calling Marinetti from an init Stephen Heumann <stephen.heumann@gmail.com> - 2017-05-02 21:13 -0500

#3429 — Calling Marinetti from an init

FromStephen Heumann <stephen.heumann@gmail.com>
Date2017-04-20 22:53 -0500
SubjectCalling Marinetti from an init
Message-ID<odbvhn$d7m$1@dont-email.me>
I'm working on a IIgs system extension (an init) that uses TCP/IP. I 
would like it to be able to continually poll for incoming data and send 
responses as long as GS/OS is running (regardless of the current 
application), but I don't see an entirely satisfactory way to do that.

The basic issue is that it doesn't seem to be safe to call Marinetti 
using interrupt-based timers (e.g. from a heartbeat task). This may 
appear to work as long as nothing else is using Marinetti, but if 
something else is, then I get dropped connections and other odd 
behavior. I think this is because my code may wind up calling Marinetti 
while the other program is also in the middle of a Marinetti call, and 
since Marinetti is not (fully) reentrant this corrupts its state.

My understanding is that it's generally safe to make most tool calls in 
such situations if the system busy flag is not set (and if it is set 
then the scheduler can be used to defer the operation until it's not), 
but this doesn't seem to make a difference with Marinetti. As far as I 
can tell from looking at the MOSP code, Marinetti never increments the 
busy flag, so it's not surprising that this doesn't work.

My current workaround for this issue is to use a run queue task 
instead. This more or less works in desktop programs, but it doesn't 
work in other environments like textual shells, because they don't call 
SystemTask and therefore run queue tasks don't get run. (There can also 
be an issue if a desktop program is busy with something and doesn't 
call SystemTask for a long time.)

Am I missing some good way to do what I want? If not, should Marinetti 
be changed to make this possible? I think at a minimum it would have to 
be modified to increment the busy flag around any non-reentrant 
sections of code. It seems like this would be useful for a fairly wide 
range of programs, including servers and programs that provide some 
kind of system service using a TCP/IP connection.

-- 
Stephen Heumann

[toc] | [next] | [standalone]


#3467

Fromandrew.roughan@writeme.com
Date2017-05-02 16:58 -0700
Message-ID<8234f03b-e97d-4c85-b9d2-a5ca53154225@googlegroups.com>
In reply to#3429
Hi,

Sorry for the delay in getting back to you. In the mean time I passed this on to Richard and have received a response from him.

On Friday, April 21, 2017 at 1:53:25 PM UTC+10, Stephen Heumann wrote:
> The basic issue is that it doesn't seem to be safe to call Marinetti 
> using interrupt-based timers (e.g. from a heartbeat task).

It is not.

> Am I missing some good way to do what I want?

Setting a task into the scheduler to call TCPIPPoll seems like the correct way to do what you want.

> If not, should Marinetti be changed to make this possible? 

Richard is not able to remember why the busy flag was not used. He'd like to look into this more. In the meantime, I think we can explore this direction.
I'll get you a build that sets and clears the busyflag around each toolcall.

Regards,
Andrew

[toc] | [prev] | [next] | [standalone]


#3468

Fromandrew.roughan@writeme.com
Date2017-05-02 17:03 -0700
Message-ID<e2f71c27-ca04-4470-ae9f-1169c83e2178@googlegroups.com>
In reply to#3467
I've created ticket https://sourceforge.net/p/marinetti/feature-requests/35/ for this.

[toc] | [prev] | [next] | [standalone]


#3469

FromStephen Heumann <stephen.heumann@gmail.com>
Date2017-05-02 21:13 -0500
Message-ID<oebe6n$lbl$1@dont-email.me>
In reply to#3467
Hi Andrew,

On 2017-05-02 23:58:16 +0000, andrew.roughan@writeme.com said:
> Sorry for the delay in getting back to you. In the mean time I passed 
> this on to Richard and have received a response from him.

Thanks for looking into this. As you can probably guess, this relates 
to AFPBridge. Basically, whenever an AFP-over-TCP connection is open, I 
want to have a way to get control periodically (every couple seconds or 
so) and be able to send or receive data over the TCP connection. This 
is necessary to check for new messages from the server and to 
periodically send a 'tickle' message to the server to keep the 
connection alive.

The currently released version uses a run queue task for this, but that 
only works in desktop programs, and even there run queue tasks may not 
get run for a while if the program is busy with something. It also 
offers the 'fake sleep' option as a workaround, but that is really a 
hack and doesn't work with all servers.

>> If not, should Marinetti be changed to make this possible?
> 
> Richard is not able to remember why the busy flag was not used. He'd 
> like to look into this more. In the meantime, I think we can explore 
> this direction.
> I'll get you a build that sets and clears the busyflag around each toolcall.

That would be great. If you can send that to me, I can make a test 
version of AFPBridge that uses a heartbeat task (or an AppleTalk 
InstallTimer call) plus the scheduler for its periodic task, and see 
how it works.

-- 
Stephen Heumann

[toc] | [prev] | [standalone]


Back to top | Article view | comp.sys.apple2.programmer


csiph-web