Re: Looking for advice/opinions

[Matthew Flatt <mflatt@cs.utah.edu>]

Sorry for the delay.

Quoting Eddie Corns:
> I realise there would be a place for threads here but at the same
> time it seems like it might be expensive to invoke a thread for each
> individual request, especially as it is not uncommon to poll hundreds
> or even thousands of devices in one go. It seems natural to me
> (because I've used them before probably) to use callbacks. So
> (simplifying a bit) I would attach a 2 arg procedure to the outgoing
> request (to pass back the return value and success code) to be called
> after the response arrives (detected using SIGIO). Rather than trying
> to handle callbacks being invoked at an arbitrary time I think it
> might be easier to have a wait procedure that suspends the thread,
> handles all responses that have arrived and that continue to arrive
> until there's none left outstanding and then return.

Overall, that makes sense.

I recommend avoiding SIGIO. MzScheme's C interface will let you
register a set of file descriptors to be used with select(). In
particular, scheme_block_until() takes two functions: one to check
whether to stop blocking, and one to register file descriptors for
select() when MzScheme discovers that no thread wants to run.

> Does anyone have pointers to anything similar I can learn from/steal?

MzScheme's implementation contains lots of examples, though many are
fairly elaborate. The implementation of fd-based input and output might
be a reasonable thing to look at (in "port.c", look for "fd input port"
and "fd output port").

> Can I achieve this without getting involved in the internals of mzscheme?
> Making it an add-on would be better.

Yes: everything you want to do is supported by the C interface.

> Can I use SIGIO without affecting the normal operation of mzscheme?
>
> (Does SIGIO actually work? nobody seems keen to use it.  Actually I'm still
> investigating alternatives here such as aio.)

Since MzScheme wants to sleep with select(), SIGIO isn't going to be
much use. (And I could go on and on about problems with signals...)

> A pragmatic issue - the leading contender for the actual SNMP library
> uses glib (the gtk/gnome C library) is anyone aware of
> interoperability problems with mzscheme? I've removed the code which
> depends on the glib event loop (I hope). Initial experiments were
> encouraging.

Don't know offhand.

Matthew