Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.apple2.programmer > #3429 > unrolled thread
| Started by | Stephen Heumann <stephen.heumann@gmail.com> |
|---|---|
| First post | 2017-04-20 22:53 -0500 |
| Last post | 2017-05-02 21:13 -0500 |
| Articles | 4 — 2 participants |
Back to article view | Back to comp.sys.apple2.programmer
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
| From | Stephen Heumann <stephen.heumann@gmail.com> |
|---|---|
| Date | 2017-04-20 22:53 -0500 |
| Subject | Calling 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]
| From | andrew.roughan@writeme.com |
|---|---|
| Date | 2017-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]
| From | andrew.roughan@writeme.com |
|---|---|
| Date | 2017-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]
| From | Stephen Heumann <stephen.heumann@gmail.com> |
|---|---|
| Date | 2017-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