On Wed, Apr 15, 2009 at 11:43:10AM -0400, Marc Roessler wrote:
> > You can't use the same fd in SIGEV_PULSE_INIT that you send
> > on in ionotify.
> But isn't this exactly what select() does? One fd for reading and writing, and on that very fd we block?

No it uses SIGEV_SIGNAL_THREAD and blocks in SignalWaitinfo().

> 
> > How do you intend to block? If you intend to 
> > call MsgReceive on your own channel then you can:
> > 
> > coid = ConnectAttach_r(ND_LOCAL_NODE, 0, chid, _NTO_SIDE_CHANNEL, 0);
> How is this channel linked to the fd that I just opened then?

They're not really other than that you're using fd to send
the event to the server.  Pulses are sent to channels so if
you're not calling MsgReceive you can't use a pulse.

> I don't intend to call MsgReceive on my channel, I'd just like to
> wait (i.e. ionotify block) for messages from the server. When the server has a message for us, I'd ask for it using a 
MsgSend() message. Same as select/read, but with a different meaning for "read".
> 

I don't know what you mean by 'ionotify block'.

> I could use select() just as well as poll(), correct?

Sure, select() calls poll().

> 
> > You'll have to segment them some how.  Maybe always have the client do a
> > read into a buffer big enough to hold the largest struct it'll ever get
> > and always reply with a full struct (datagram like) or EOF if there's
> > none left
> As I said, there is no upper limit. This is part of a framework with auto-generated code, and there really is no limit
 to the size of the data transferred (other than the length value must probably fit in 32bit).
> Our messages already are segmented, it's multiple blobs of data queued once at a time. The irony is that we're losing 
this segmentation again when doing message passing (which is itself already segmented, as the name implies!).
> 
> That's how the idea came to use the pulse/notification to signal the size of the next message. The client then could 
allocate this amount of memory and call MsgSend(), knowing that the reply would fit into the buffer.
> 

> What do you think?

Sounds like it may be doable but again if you use a pulse
you'll have to MsgReceive it on a channel.  There also may
be a window where the ionotify() returns right away if
there's data available at the time of the call and no event
is armed in the server.

> 
> Greetings,
>  Marc
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post27083
> 

> On Wed, Apr 15, 2009 at 11:43:10AM -0400, Marc Roessler wrote:
> > 
> > > You'll have to segment them some how.  Maybe always have the client do a
> > > read into a buffer big enough to hold the largest struct it'll ever get
> > > and always reply with a full struct (datagram like) or EOF if there's
> > > none left
> > As I said, there is no upper limit. This is part of a framework with auto-generated code, and there really is no 
limit to the size of the data transferred (other than the length value must probably fit in 32bit).
> > Our messages already are segmented, it's multiple blobs of data queued once at a time. The irony is that we're 
losing this segmentation again when doing message passing (which is itself already segmented, as the name implies!).
> > 
> > That's how the idea came to use the pulse/notification to signal the size of the next message. The client then could
 allocate this amount of memory and call MsgSend(), knowing that the reply would fit into the buffer.
> > 
> 
> > What do you think?
> 
> Sounds like it may be doable but again if you use a pulse
> you'll have to MsgReceive it on a channel.  There also may
> be a window where the ionotify() returns right away if
> there's data available at the time of the call and no event
> is armed in the server.

This also isn't standard in that the server would have to
alter the payload of the pulse.  A more 'standard' way would
be something like:

for (;;) {
	poll(&pfd, 1, -1);

	for (;;) {
		ioctl(fd, FIONREAD, &nread);
		if (nread == 0)
			break;
		if (nread > bufsize) {
			realloc(buf, nread);
			bufsize = nread;
		}
		read(fd, buf, nread);
	}
}

-seanb